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ABSTRACT 

The  purpose  of  this  thesis  is  to  describe  a  deficiency  in  current  Marine  Corps 
logistic  communication,  investigate  various  technical  solutions  and  select  an 
appropriate  design  to  eliminate  this  deficiency.  The  intention  is  not  to  answer  all  of 
the  questions  related  to  the  topic,  but  to  demonstrate  that  technology  has  advanced  to 
a  point  where  it  is  possible  to  provide  an  inexpensive  solution  to  this  particularly 
difficult  problem.  Although  further  research  will  be  required,  this  thesis  will  indicate 
that  the  technology  is  not  only  conceivable,  practical  and  efficient,  but  well  within 
reach.  The  thrust  is  to  marry  a  relatively  new,  but  proven,  technology  with  a  real 
world  problem  and  to  direct  further  attention  to  the  effort,  so  that  a  practical  solution 
can  become  a  reality.  As  a  result,  The  Marine  Corps  could  possess  a  faster,  more 
reliable  logistic  communication  system  while  deployed  and  thus  have  an  added 
advantage  durins  a  conflict. 
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I.  INTRODUCTION 

A.  PURPOSE 

The  purpose  of  this  thesis  is  to  describe  a  deficiency  in  current  Marine  Corps 
logistic  communication,  investigate  various  technical  solutions  and  select  an 
appropriate  design  to  eliminate  this  deficiency.  The  intention  is  not  to  answer  ail  of 
the  questions  related  to  the  topic,  but  to  demonstrate  that  technology  has  advanced  to 
the  point  where  it  is  possible  to  provide  an  inexpensive  solution  to  this  particularly 
difficult  problem.  Although  further  research  will  be  required,  this  thesis  will  indicate 
that  the  technology  is  not  only  conceivable,  practical  and  efficient  but  well  within 
reach.  The  thrust  is  to  marry  a  relatively  new,  but  proven,  technology  with  a  real 
world  problem  and  to  direct  further  attention  to  the  effort,  so  that  a  practical  solution 
can  become  a  reality.  As  a  result,  The  Marine  Corps  could  possess  a  faster,  more 
reliable  logistic  communication  system  while  deployed  and  thus  have  an  added 
advantage  during  a  conflict. 

B.  CHAPTER  DESCRIPTION 

The  following  chapter  of  this  thesis  will  be  a  mission  element  need  statement. 
The  purpose  will  be  to  describe  a  deficiency  in  Marine  Corps  logistic  communication 
and  processing  at  the  local  level.  "Local  level"  is  defined  as  that  communication  and 
processing  of  logistic  requests  from  the  actual  customer  (maintenance  clerk,  company 
commander)  through  the  logistics  chain  of  command  to  the  force  service  support 
group.  The  emphasis  will  be  placed  on  deployed  operations  but  will  not  rule  out 
applications  in  garrison.  The  priority  of  this  deficiency  will  be  discussed  and  a 
preliminary  cost  estimate  provided.  No  solutions,  however,  will  be  addressed  at  this 
point.  The  intention  will  be  purely  to  demonstrate  that  there  is  a  deficiency  in  Marine 
Corps  logistic  operations. 

The  third  chapter  will  highlight  current  technological  advancements  in  the  field  of 
packet  radio  computer  networks.  The  fact  that  packet  radio  computer  networks  are 
not  at  the  leading  edge  of  technology,  but  are  a  proven  technology,  will  also  be 
demonstrated  in  this  chapter.  Problems,  advantages  and  options  will  be  elaborated  on 
in  a  generic  sense  i.e.,  not  necessarily  related  to  the  problem  identified  in  the  mission 
elements  needs  statement. 
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The  fourth  chapter  titled  "design"  will  develop  a  prototype  design  and  will  discuss 
system  specifications.  These  specification  will  be  as  precise  as  possible  based  on 
currently  available  statistics  and  experience.  Many  aspects  of  the  network  will  be 
examined  and  specifications  will  be  described  for  the  hardware.  This  will  be 
accomplished  by  breaking  the  network  design  down  into  sections.  First,  we  will  study 
the  required  attached  equipment  at  a  typical  repeater  node,  then  we  will  examine  the 
network  or  the  method  of  communication  between  nodes,  and  finally  we  will  examine 
the  control  node  or  station. 

The  last  chapter  will  point  out  each  of  the  positive  and  negative  aspects  of  the 
proposed  system  and  recommend  a  direction  for  further  research.  A  summary 
proposing  certain  future  actions  and  considerations  will  conclude  this  thesis. 

Appendix  A  is  a  list  or  acronyms  used  through  the  thesis.  Each  acronym  is 
explained  to  clarify  the  use  of  terms  unique  to  the  military. 

C.       DESIGN  PRINCIPLES 

A  number  of  principles  will  be  applied  and  emphasised  throughout  this  thesis. 
These  principles  may  seem  elementary  but  a  reemphasis  of  the  basics  is  important 
when  dealing  with  critical  systems,  especially  when  human  lives  are  at  stake.  As  such, 
they  are  described  in  the  next  four  paragraphs  to  clarify  basic  design  considerations 
and  constraints. 

1.  Simplicity 

The  first  design  principle  is  simplicity.  This  may  be  an  overworked  concept. 
but  it  is  evident  from  the  catastrophic  results  of  many  computer  systems  that  the 
designers  have  often  times  dismissed  simplicity  as  an  important  constraint.  The  design 
of  this  computer  network  is  only  as  complex  as  the  problem  dictates.  The  basic 
concept  is:  first,  identify  the  problem;  second,  investigate  the  kind  of  tools  that  can  be 
used  to  solve  the  problem;  then  finally,  develop  a  design.  As  a  result,  design  functions 
will  translate  directly  into  solutions  to  the  previously  identified  problem  without 
unneeded  complexity. 

2.  Customer  First 

The  second  principle  is  the  emphasis  on  customer  needs.  Throughout  this 
thesis,  the  basic  customer  needs  will  be  delineated  and  solutions  will  be  developed  in 
strict  relation  to  those  needs.    The  basic  needs  of  the  customer  (the  maintenance  clerk 


^he  customer  is  that  person  that  initiates  a  logistic  request. 
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etc.)  will  be  emphasized  as  opposed  to  the  needs  of  the  system  or  those  of  the  source 
of  supply.  The  source  of  supply  and  the  system  will  be  developed  to  serve  the 
customer,  instead  of  the  other  way  around.  If  functions  do  not  serve  a  real  customer 
need,  an  alternative  will  be  sought  that  will  fulfill  these  requirements.  If  an  acceptable 
alternative  cannot  be  found,  then  no  change  to  current  operating  procedures  should  be 
made.  Although,  again,  this  may  seem  overly  simplistic  because  of  the  complexity  of 
computer  system  development,  it  is  possible  to  develop  a  system  that  upon  completion 
has  lost  sight  of  its  original  goal. 

3.  Flexibility 

The  third  principle  is  flexibility.  It  must  be  kept  in  mind  that  a  computer 
system  is  more  than  just  a  machine.  By  definition,  people  are  an  integral  component  of 
any  computer  system  [Ref.  1:  p.  22].  As  a  result,  with  emphasis  on  the  word  'system', 
as  much  flexibility  as  possible  will  be  built  into  the  design.  This  is  to  insure  that  when 
a  request  is  made  and  something  is  not  quite  in  the  right  format,  the  request  will  not 
be  returned  but  will  be  diverted  to  a  manual  review  process  and  or  an  error  correction 
process.  There  will  be  rules  and  procedures,  of  course,  but  one  of  the  goals  of  the 
system  is  to  be  able  to  accommodate  all  but  the  most  grievous  of  errors.  This  is 
especially  necessary  in  combat  situations  where  bureaucratic  procedure  is  not  a  suitable 
reason  for  delay. 

4.  Reliability 

The  fourth  concept  is  reliability.  In  military  operations  reliability  is  one  of  the 
highest  priorities.  The  proposed  design  will  consider  reliability  over  most  other 
considerations.  As  a  result,  back-up  procedures  will  be  implemented.  As  much  effort 
as  possible  will  be  given  to  providing  the  system  user  with  alternative  means  of 
communicating  and  processing.  In  addition,  the  programs  should  contain  means  with 
which  to  identify  failure  and  any  avenue  around  failure,  so  that  the  system  will  be  as 
reliable  as  possible.  In  view  of  these  safeguards,  the  system  should  operate  under  any 
weather  conditions,  in  urban  areas  and  or  in  the  jungle,  in  mountains  or  on  flat  lands, 
in  combat  or  in  garrison.  The  task  of  adding  and  deleting  members  to  and  from  the 
network  should  also  be  accomplished  with  ease.  Routing  should  be  flexible  enough  to 
allow  for  redundant  means  of  communication.  Thus,  we  will  strive  to  provide  a  robust 
network  which  will  be  able  to  operate  even  in  the  most  harsh  environments. 
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II.  MISSION  ELEMENT  NEED  STATEMENT 

A.       BACKGROUND 

In  order  to  obtain  a  full  appreciation  of  the  problem  of  communicating  logistic 
demands  during  a  Marine  amphibious  landing,  a  basic  understanding  of  the  landing 
force  structure  is  necessary.  A  brief  description  of  this  structure  will  be  outlined  in  the 
following  paragraphs. 

A  Marine  amphibious  force  is  a  mobile  and  flexible  unit  that  must  be  able  to 
adapt  to  changing  environments.  For  example,  while  aboard  ship  the  landing  force 
reports  to  the  Navy.  Once  ashore,  however,  it  reports  via  Army  channels.  The 
Marines  must,  therefore,  rapidly  adapt  themselves  to  both  organizations.  This  usually 
causes  a  great  deal  of  difficulty  when  planning  and  coordinating  support  functions. 
This  problem  is  complicated  further  by  the  fact  that  Marines  possess  both  air  and 
ground  forces.  The  Marine  air  element  must  coordinate  with  the  Navy  aboard  ship, 
but  must  deal  with  the  Air  Force  missions  and  capabilities  while  ashore. 

The  Marine  landing  force  itself  is  divided  into  four  parts:  a  headquarters  element, 
an  air  element,  a  ground  element  and  a  support  element.  Depending  on  the  size,  this 
configuration  can  be  formed  into  three  types  of  landing  forces:  a  Marine  Amphibious 
Force  (MAF),  which  is  the  largest  force  and  is  formed  around  a  division;  a  Marine 
Amphibious  Brigade  (MAB),  which  is  built  around  a  regiment;  and  a  Marine 
Amphibious  Unit  (MAU),  which  is  the  smallest  configuration  and  is  formed  around  a 
battalion. 

The  headquarters  element  consists  of  the  landing  force  commander  and  his  staff, 
along  with  a  small  group  of  communicators. 

The  air  element  consists  of  helicopter  support  and  for  larger  operations,  fixed 
wing  aircraft.  The  air  defense  and  air  control  missions  are  also  assigned  to  the  air 
element. 

The  ground  element  is  commanded  by  the  infantry  unit  commander.  Under  the 
infantry  unit  commander  are  a  number  of  support  sections  i.e.,  tanks,  recon,  amtracks, 
communicators,  combat  engineers,  etc.  Artillery  is  included  here,  but  artillery's  mission 
is  also  to  support  the  entire  landing  force,  not  just  the  ground  units. 
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The  support  element  provides  most  of  the  logistic  support  to  the  landing  force. 
Supply,  maintenance,  engineering,  medical,  dental,  motor  transport  and  landing 
support  fall  into  this  category. 

Marine  amphibious  logistic  support  is  for  the  most  part  centralized  at  the 
support  element.  Thus,  a  unit  requiring  logistic  support  must  communicate  its  requests 
to  the  support  element.  During  deployment  these  requests  are  normally  processed 
manually. 

The  major  problem  dealt  with  in  this  thesis  is  how  logistic  communication  and 
processing  is  accomplished.  It  will  also  be  shown  that  both  the  logistic  communication 
and  the  local  processing  aspects  of  this  procedure  are  very  time  consuming.  To 
demonstrate  this  point,  supply  demands,  which  are  the  most  numerous  and  time 
intensive,  will  be  examined  in  detail.  The  ideas  generated  from  this  examination  could, 
however,  be  easily  applied  to  other  types  of  logistic  transactions  i.e..  maintenance, 
motor  transport,  engineering,  etc.  The  term  "local  level"  will  be  used  to  describe  this 
form  of  communication  and  processing  procedures. 

B.       MISSION  AREA 

The  force  service  support  groups  (FSSG)  of  the  Marine  corps  provide  logistic 
support  within  their  capabilities  to  the  MAF's.  The  supply  battalion  within  the  FSSG 
maintains  the  responsibility  for  providing  responsive  supply  support  for  most  classes  of 
supply  material  required  by  MAF  units.  Class  III  (petroleum  products)  supply  support 
is  provided  by  the  FSSG  engineer  battalion  while  unique  aviation  items  are  provided 
by  the  wing  supply  staff."  Implied  in  these  mission  statements  is  the  requirement  to 
establish  procedures  for  processing  logistics  requests  initiated  by  MAF  customers.  The 
faster  these  requests  are  processed,  starting  with  the  customer  identification  of  need, 
the  more  responsive  the  supply  support.  Thus,  to  insure  responsive  supply  support,  it 
is  the  responsibility  of  these  support  activities  to  establish  systems  that  will  process 
requests  in  the  most  rapid  manner  possible,  whether  in  garrison  or  while  deployed. 


"This  is  verified  bv  the  mission  statement  of  the  Marine  Corps  3rd  Force  Service 
Support  Group,  Okinawa,  Japan. 
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C.       MISSION  ELEMENT  NEEDS 

1.  Problem  Identification 

Over  the  years,  the  military  has  succeeded  in  developing  extremely  capable 
logistic  communications  systems  over  long  distances.  Military  personnel  can  send  a 
supply  document  from  Okinawa  to  any  DOD  source  of  supply  via  ALTODIN  (the 
military  data  communication  system).  This  can  be  accomplished  by  filling  out  a  1348 
Navy  form  or  by  keypunching  the  appropriate  information  onto  a  card  or  magtape 
which  is  dropped  off  at  the  nearest  communication  center.  The  communication  center 
processes  this  information  as  it  would  a  naval  message,  in  accordance  with  its  priority, 
and  once  inserted  into  AUTODIN  the  message  is  delivered  to  the  source  of  supply  in 
minutes,  if  not  seconds.  At  most  sources  of  supply,  these  requests  are  processed 
immediately  (or  within  a  few  hours)  against  on  hand  stocks.  Status  is  then  instantly 
sent  back  to  the  originating  communication  center. 

The  question  may  then  be  asked  by  those  who  have  worked  with  supply 
documents  and  status  in  the  Fleet  Marine  Force:  "If  we  have  such  a  fast 
communication  system,  why  does  it  take  weeks  for  status  to  be  posted  to  supply  or 
maintenance  reports?"  The  answer  to  this  question  is  that  the  local  processing  by  the 
communications  center,  and  the  local  systems,  slows  the  process  considerably.  The 
difference  between  the  ability  of  the  communications  center  to  transmit  and  receive 
messages  from  its  electronic  system  and  the  ability  of  users  to  deliver  and  receive 
information  from  the  communication  center  is  significant. 

The  point  to  be  made  here  is  that  communicating  logistic  data  across  the 
world  from  Okinawa,  to  Albany,  Georgia,  is  not  the  problem.  The  actual  problem  is 
processing  and  communicating  logistic  information  from  Motor  Transport  Section,  HQ 
Company  4th  Marines  at  Camp  Shwab,  Okinawa  to  the  3rd  FSSG  communication 
center  at  Camp  Kinser,  Okinawa.  To  make  matters  worse,  how  does  the  logistic  clerk 
communicate  logistic  demands  from  Unchon,  Korea,  or  Dingralin  Bay  in  the 
Phillipines,  to  his  first  source  of  supply  and  then  to  the  3rd  FSSG  communication 
center  in  Okinawa?  The  problem  is  not  the  actual  transmission  speed,  which  takes 
only  seconds,  but  in  getting  the  message  to  the  communication  center  i.e..  local 
processing  and  communicating. 

2.  Problem  Examination 

Since  this  thesis  addresses  the  logistic  communication  of  a  deployed  unit,  we 
will  examine  the  process  from  this  point  of  view.   These  procedures  are  similar  to  those 
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used  in  garrison,  but  a  look  at  deployed  operations  demonstrates  the  problem  more 
clearly.  While  deployed,  a  logistic  request  is  delivered  by  the  customer  to  the  first 
source  of  supply  (the  issue  point).  The  issue  point  processes  the  request  and.  if 
necessary,  communicates  it  back,  to  a  garrison  source  of  supply.  If  the  demand  cannot 
be  filled  at  the  garrison  source,  it  is  delivered  to  the  supporting  communication  center 
for  transmission  to  a  DOD  source  of  supply.  So.  why  is  there  such  a  local  delay 
problem?   There  are  essentially  three  factors  to  consider: 

One:        The  link  between  the  customer  and  the  issue  point 
is  a  difficult  and  slow  communication  procedure. 

Two:        Processing  at  the  issue  point  is  bureaucratic  and  slow. 

Three:     The  numerous  steps  involved  in  processing  demands 
at  the  local  level  decreases  response  time. 

a.    The  Link 

Problem  #  1  is  the  keystone  of  this  thesis.  The  ability  of  the  customer  to 
communicate  a  request  while  deployed,  to  the  issue  point,  is  often  an  overwhelming 
problem,  and  a  frustrating  one  in  garrison. 

(1)  Communication.  Consider  the  simplest  case:  a  Marine  Amphibious 
Unit  landing.  Where  is  the  source  of  supply?  Initially,  it  is  kept  aboard  ship.  When 
the  issue  point  is  aboard  ship,  how  does  a  shore  unit  deliver  a  request  to  the  issue 
point?  If  any  support  is  provided  at  all.  the  request  must  be  voice  communicated  to 
the  tactical  logistic  operation  center  (TLOC).3  This  process  consumes  valuable 
communication  capabilities,  using  voice  channels  that  are  critical  for  command  and 
control.  The  process  is  troublesome,  so  much  so,  that  it  is  usually  simply  not 
attempted.  At  this  stage  of  the  amphibious  landing  there  is  limited,  if  any.  ability  to 
communicate  logistic  data. 

Once  ashore,  the  issue  point  may  begin  to  support  the  forces  more 
efficiently.  But  what  about  the  unit  20  or  30  kilometers  inland?  What  type  of  support 
can  it  expect  in  a  hostile  environment?    The  only  practical  means  of  communicating 


The  TLOC  is  the  section  in  the  support  element  that  accepts  all  customer 
ts  and  directs  support  action.     It  can  be  though  of  as  the  support  element's 


request 
operation  center 


16 


supply  requirements  is  via  courier.  Will  the  commander  dedicate  a  man  and  a  vehicle 
to  go  on  a  supply  run  back  to  the  beach?  This  may  be  considered,  but  it  will  certainly 
not  be  accomplished  in  a  responsive  manner.  Within  the  existing  system,  we  talk,  in 
terms  of  days  while  today's  modern  communication  and  processing  technologies  can 
accomplish  such  tasks  in  milliseconds. 

(2)  Transportation.  A  second  difficulty,  associated  with  the  logistic  link 
between  the  customer  and  the  support  element,  is  transportation.  First,  let  us  assume 
that  the  support  element  is  now  ashore.  In  such  cases,  the  primary  means  of 
communication  between  the  customer  and  the  issue  point  is  by  courier.  Unless  the 
customer  is  within  walking  distance,  the  courier  will  require  motor  transportation.  This 
is  a  time  consuming  activity  that  requires  detailed  planning  and  often  must  be  shared 
with  other  missions.  Waiting  for  transportation  further  delays  the  communication  of 
logistic  requests. 

On  the  other  hand,  let  us  assume  that  the  support  activity  is  still 
aboard  ship  when  a  request  is  received  and  that  the  supply  block  is  embarked,  enabling 
a  warehousemen  to  pull  the  item  off  the  shelf  (often  not  the  case).  The  next  question 
is,  how  will  the  item  be  delivered  ashore?  This  new  transportation  request  must 
compete  with  other  critical  demands  for  the  extremely  limited  transportation  assets 
available  between  ship  and  shore  during  an  amphibious  landing.  This  is  another  form 
of  transportation  delay. 

(3)  Procedures.  A  third  factor  associated  with  the  logistic  link  concerns 
the  procedures  used  by  customers.  A  logistic  request  is  initiated  by  a  unit  in  one  of  the 
landing  force  elements,  for  example.  This  request,  in  some  cases,  must  flow  up  the 
unit's  chain  of  command  to  the  support  activity.  In  other  words,  a  request  made  by  a 
company  commander  must  be  approved  by  the  company's  battalion,  regiment  and 
division  before  it  is  provided  to  the  support  activity.  These  steps  are  necessary  in  order 
to  maintain  control  over  demands  and  to  keep  higher  echelons  of  command  informed. 
It  also  causes  considerable  delays  and  bureaucratic  frustrations.  For  a  unit  well  inland, 
the  effort  and  dedication  of  assets  necessary  for  proper  logistic  support  is  not  perceived 
to  be  worthwhile  in  the  short  run. 

In  time,  for  the  following  reasons  the  difficulty  of  communicating 
logistic  transactions  to  the  issue  point,  the  limited  transportation  available  for  logistics 
support,  and  the  procedures  that  require  all  echelons  of  command  to  approve  certain 
requests,  logistics  support  falls  far  behind  the  actual  need.    This  time  lag  is  often  a 
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matter  of  days,  if  not  weeks.  The  logistic  support  link  is  a  very  complex  process 
requiring  the  support  of  other  functions  such  as  transportation  and  communications. 
For  a  MAB  or  MAF  the  complexity  and  delay  become  even  more  significant.  Under 
these  situations  units  are  even  more  spread  out,  making  it  more  difficult  to 
communicate  demands  to  issue  points.  Add  this  complexity  to  a  live  combat 
environment  and  the  potential  for  improvement  is  clearly  evident. 
b.    Local  Processing 

The  second  major  problem  at  the  local  level  is  the  fact  that  processing  at 
the  issue  point  is  extremely  slow.  A  description  of  several  of  these  processes  will  be 
discussed  in  the  following  paragraphs. 

Class  IX  (repair  part)  requests  are  normally  filled  out  on  80  card  column 
manual  forms  commonly  referred  to  as  4  cards.  The  customer  is  required  to  do  all  the 
required  research  to  identify  the  proper  stock  number,  the  unit  of  issue,  etc.  These  4 
cards  are  then  sent  by  courier  to  the  issue  point.  If  the  supply  platoon  is  not  busy, 
however,  the  customer  may  receive  an  over-the-counter  issue.  Most  of  the  time,  the 
customer  can  expect  to  submit  the  4  cards  on  one  day,  and  pick  up  the  parts  on  the 
next  day.  One  whole  day  is  wasted  at  this  point  alone.  In  order  to  understand  why 
over-the-counter  issue  service  is  not  provided  on  all  occasions,  it  is  necessary  to  take  a 
closer  look  at  the  issuing  process. 

There  is  a  tendency  among  supply  officers  to  throughly  research  all 
requests  prior  to  a  stock  check.  Primarily,  this  is  done  to  insure  that  incorrect  stock 
numbers  are  not  counted  as  stock  denials,  which  could  adversly  affect  the  fill  rate.  The 
research,  which  validates  each  stock  number,  takes  up  a  lot  of  time  and  is  one  reason 
for  processing  delays.  Another  reason  is  the  fact  that  customers  normally  deliver  a 
large  number  of  requests  at  one  time.  This  happens  mainly  because  distance,  or 
vehicle  availability,  prohibit  frequent  trips  to  Supply.  As  a  result,  one  customer  may 
tie  up  Supply  for  an  hour  or  more.  This  is  a  typical  example  of  a  queue  with  a  high 
service  time  variance  in  which  the  queue  length  increases  progressively.  In  view  of 
these  problems,  customers  simply  find  it  easier  to  leave  the  paper  work  off  at  Supply 
and  pick  it  up  later. 

Once  an  item  is  issued,  the  processing  of  demands  at  the  issue  point  is  also 
a  time  consuming  task.  The  proper  transactions  are  processed  on  an  IBM  Series  1 
computer.  Once  enough  transactions  have  been  accumulated,  a  batch  update  formats 
the  transactions  on  a  diskette  for  later  transmission  to  the  next  source  of  supply.    This 
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could,  and  usually  does,  produce  days  of  delay.  If  experienced  people  are  running  the 
update,  and  if  the  update  goes  smoothly,  a  one-day  delay  may  occur.    Time  has  proven 
though  that  this  equipment  is  rarely  operated  by  experienced  personnel.    As  a  result, 
two  or  three  days  are  often  lost  in  trying  to  get  the  update  to  run  properly. 
c.    Many  Steps 

The  fact  that  there  are  numerous  steps  involved  in  processing  a  request  at 
the  local  level  is  the  third  major  problem.  In  providing  supply  support  to  deployed 
units  at  the  3rd  FSSG  the  supply  support  personnel  calculated  in  1983  that  there  were 
actually  47  steps  involved  in  providing  one  small  repair  part  from  Okinawa  to  a 
deployed  unit.  These  steps  include  action  taken  by  communicators,  maintenance 
clerks,  supply  clerks,  warehousemen,  forklift  drivers,  transport  personnel,  Air  Force  air 
embarkation  personnel  and  packaging  personnel. 

D.       EXISTING  SOLUTIONS 

1.  The  Procedural  Approach 

To  lessen  the  impact  of  these  problems,  Marines  have  developed  basically  two 
procedural  approaches.  The  first  of  which  is  to  divide  up  the  support  element  into 
smaller  sections,  in  order  to  provide  support  closer  to  the  customer.  As  such,  the 
ground  and  air  elements  may  receive  their  own  support  detachment  (DET).  To 
illustrate  this  point  perhaps  each  regiment,  or  even  each  battalion,  could  receive  their 
own  DET.  This  would  provide  support  closer  to  the  customer,  in  a  decentralized 
manner,  while  lessening  the  demand  for  transportation  and  communication.  But, 
because  the  battalion  and  regiment  must  maintain  mobility,  only  a  few  items  could  be 
stocked  in  these  DET's.  This  would  trigger  a  redistribution  problem  as  a  result  of 
stocking  only  a  limited  number  of  items.  A  problem  of  this  nature  is  one  that  is 
created  when  a  customer  sends  a  request  to  the  first  source  of  supply.  That  source  of 
supply  does  not  stock  the  needed  item.  but.  possibly  one  of  the  other  issue  points  does. 
The  problem  is:  How  does  the  customer  know  which  other  issue  point  may  stock  the 
part?  The  problem  of  positioning  support  too  close  to  the  customer,  therefore,  is  that 
a  greater  communication  problem  developes  due  to  the  redistribution  of  demands. 

A  second  alternative  solution  to  the  logistic  support  problem  from  a 
procedural  perspective  is  to  avoid  the  chain  of  command.  When  a  unit  has  a  logistic 
need,  it  merely  sends  the  requests  directly  to  the  source.  The  obvious  disadvantage 
here  is  that  both  command  and  control  suffer.     Some  requests  need  to  be  filtered 


19 


through  the  chain  of  command  to  insure  their  validity  and  or  to  insure  a  proper 
allocation  of  resources  to  all  subordinates.  This  does  not  indicate  that  some  logistic 
traffic  could  not  flow  directly  to  the  support  element.  Simple  supply  requests  for  repair 
parts  normally  do  go  directly  to  the  supply  issue  point,  which  does  save  time.  In  such 
cases,  there  is  no  reason  for  higher  commands  to  review  these  demands,  since  the 
mechanic  is  the  only  one  who  really  knows  whether  or  not  the  request  is  valid. 
2.  The  Technical  Approach 

a.  DMGS 

Recently,  there  have  been  a  number  of  systems  developed  for  deployed 
units  to  perform  the  same  functions  as  a  remote  job  entry  system  (RJE)  does  but 
which  use  communication  media  that  allow  for  mobility.  RJE's  are  tied  to  fixed 
telephone  lines,  so  they  cannot  be  moved  easily.  Systems  like  the  deployed  message 
generating  system  (DMGS).  and  others,  send  logistics  transactions  from  deployed  sites 
to  the  FSSG  communications  center  via  the  same  media  used  to  transmit  naval 
message  traffic  (HF,  satellite).  The  transactions  are  held  at  the  base  data  processing 
facility,  until  the  next  SASSY4  cycle,  at  which  time  they  are  automatically  processed. 

In  the  past,  we  have  encountered  numerous  problems  with  systems  like 
DMGS.  When  trying  to  interface  with  the  varying  support  agencies  we  found  that 
they  were  inexperienced  in  processing  transactional  traffic.  This  inexperience  led  to  a 
great  deal  of  confusion,  which  resulted  in  costly  delays  and  loss  of  important  data. 

b.  DFASC 

The  deployed  force  automated  service  center  (DFASC)  was  part  of  another 
attempt  to  reduce  the  impact  of  local  processing  delay.  The  initial  idea  was  to 
accomplish  all  local  processing  within  close  proximity  to  the  customer.  Instead  of 
sending  logistic  traffic  back  to  a  garrison  computer  for  processing,  for  instance,  the 
processing  was  accomplished  at  the  deployed  site  by  a  mobile  IB VI  4341  mainframe 
computer.  The  DFASC  has  allowed  the  SML'5  to  deploy  and  operate  in  the  field 
providing  the  same  automation  services  that  the  SMU  now  provides  in  garrison.  The 
output  from  this  process  could  also  then  be  directly  entered  into  AUTODIN.  This 
concept  has  provided  a  higher  degree  of  information  management  in  the  deployed 
environment. 


4SASSY  is  the  Marine  Corps  automated  supply  system. 

-The  SMU  is  the  SASSY  management  unit  which  serves  as  the  source  of  supply 
for  issue  points  and  accepts  input  and~distributes  SASSY  output  to  customers. 
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E.  PLANNED  SYSTEMS 

None  of  the  above  systems  address  the  customer-to-issue-point  link.  However, 
there  are  a  few  systems  under  development  that  could  be  expanded  to  include  this 
concept.  The  Maritime  Prepositioned  Support  (MPS)  Decision  Support  System,  or 
MDSS,  attempts  to  provide  the  landing  force  commander  with  asset  visibility.6  The 
Combat  Service  Support  Information  System,  or  CSSIN,  attempts  to  coordinate  the 
many  blocks  of  items  sent  by  the  war  reserve  system  (WRS),  and  others,  during  a  real 
conflict  [Ref.  2].  Once  organized  and  centralized,  a  particular  item  may  be  easily 
located.  These  systems  attack  specific  problems  and  demonstrate  the  need  for  asset 
visibility  on  the  battlefield.  To  make  these  systems  more  potent,  however,  the 
associated  files  must  be  updated  rapidly  by  customers.  The  poor  link  that  exists 
between  the  customer  who  consumes  assets,  and  MDSS  or  CSSIN.  must  be  addressed 
as  an  important  constraint  before  a  solution  can  be  developed.  If  this  link  can  be 
tightened,  it  will  enhance  these  two  new  support  systems  remarkably.  Not  only  will  the 
landing  force  commander  gain  asset  visibility,  he  will  be  able  to  achieve  real-time 
visibility. 

F.  IMPACT 

The  priority  of  the  logistic  communication  problem  is  difficult  to  quantify. 
Logistics  communication  in  the  early  stages  of  an  operation,  when  the  support  element 
is  still  aboard  ship,  is  usually  poor.  Nevertheless,  there  are  those  who  would  argue  that 
logistics,  in  the  early  stages,  are  not  important.  This  is  assuming  that  equipment  will 
operate  the  way  it  is  supposed  to.  once  it  rolls  ashore.  However,  it  is  always  better  to 
have  some  sort  of  equipment  back-up  to  rely  on  in  complex  operations  such  as  an 
amphibious  landing.  Even  after  the  support  element  is  ashore,  as  previously 
mentioned,  logistics  requests  are  usually  not  made  because  of  the  time  element 
involved.  In  view  of  this,  whenever  a  major  weapons  system  fails  the  needed  parts  are 
often  obtained  by  cannibalizing  like  items.  These  tactics  have  short  term  advantages, 
but  in  a  lengthly  campaign  could,  and  will,  prove  disastrous. 

Because  MAF  units  cannot  easily  communicate  logistics  data,  they  are  forced  to 
operate  without  needed  support.  As  we  become  more  dependent  on  machines,  we 
must  learn  to  provide  for  more  rapid  means  to  support  this  equipment.  Without  the 
proper  support,  our  equipment  status  will  quickly  decline. 


information  obtained  from  interview  with  Lt  Col  Donald  E  Mears  HQMC  1  +  L 
28  Aug  19S6. 
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In  order  to  get  some  feel  for  the  possible  impact  of  poor  logistic  support  while 
deployed  in  a  prolonged  operation,  consider  a  garrison  MAF.  Most  MAF's  maintain 
an  equipment  readiness  rate  of  close  to  90%.  In  peacetime,  a  garrison  MAF  processes 
30-50  thousand  supply  demands  in  a  month.'  Consider  that  there  would  be  a  much 
higher  failure  rate  while  deployed,  if  for  no  other  reason,  than  because  the  equipment  is 
run  longer.  Would  we  be  able  to  process  the  30-50  thousands  of  demands  a  typical 
MAF  now  processes  monthly,  in  the  first  30  days?  Even  on  large  exercises,  we  are 
only  able  to  process  100  to  150  transactions  a  day  which  is  only  1  10  of  the  garrison 
volume.  Could  we  really  hope  to  maintain  high  equipment  readiness  using  the  current 
logistic  communication  system  previously  outlined?  It  is  obvious  that  the  equipment 
readiness  rate  will  depend  greatly  on  the  ease  of  being  able  to  request  support. 
Streamlining  and  facilitating  these  logistics  procedures  will  provide  a  clear  advantage. 

G.       COST  ESTIMATIONS 

In  the  private  sector  Packet  Radio  has  been  used  to  solve  similar  logistic 
communication  problems.8  In  1980  the  projected  cost  of  a  packet  radio,  in  five  years 
time  was,  S5.000  [Ref.  3:  p.  1].  Fielding  down  to  the  company,  batten-  and  or 
squadron  level  would  require  approximately  200  radios  per  MAF.  Table  1  show 
estimated  costs.  Of  course  these  are  extreme  cost  estimates  not  based  on  in-depth 
research  but  they  do  provide  a  tentative  cost  approximation. 

H.      SUMMARY 

The  preceding  mission  elements  needs  statement  has  attempted  to  demonstrate 
the  fact  that  requesting  logistic  support  in  garrison,  and  especially  while  deployed,  is  a 
complex  coordination  problem  which  may  take  days  to  complete.  The  following 
chapters  will  explore  the  possibilities  of  using  packet  radios  to  improve  logistic 
responsiveness  within  deployed  forces. 


'Supplv  demand  rate  obtained  from  official  Marine  Corps  records  for  the  months 
Oct  to  July  S6. 

8Phone  conversation  with  Federal  Express  Public  Relations  Department  on  29 
Dec  86  indicated  thev  use  packet  radios  to  trace  packages.  Each  truck  is  equiped  with  a 
packet  radio  so  a  delivery  confirmation  can  be  sent  to  a  central  computer  immediately. 


TABLE  1 
PACKET  RADIO  NETWORK  COSTS  ESTIMATES 

200  X  3  (MAF'S)  -  600  X  S5.000  =  S  3  000  000 

Cost  of  Snares  =  S3  000  000 

Software  Costs  Using  COCOVIO  =  S      054  000 

Testing  and  Development  =  S  1   000  000 

Total  Cost  =  S  7  054  000 

Deployment  Cost  =  S      200  000  per  year 
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III.  PACKET  RADIO  TECHNOLOGY 

A.  INTRODUCTION 

Packet  radio  was  created  by  merging  packet  switching  with  standard  radio 
technology.  This  technology  takes  advantage  of  the  ability  to  communicate  between 
computers  using  radio  wave  propagation,  instead  of  the  traditional  hardwire  media.  In 
other  words,  if  someone  has  a  packet  radio  they  will  be  able  to  communicate  with  a 
distant  computer  by  linking  to  that  computer  via  radio  waves,  instead  of  the  standard 
telephone  lines. 

Packet  radio  borrows  heavily  from  an  earlier  technology  known  as  packet 
switching.  Packet  switching,  which  was  developed  primarily  for  the  DOD  ARPANET 
in  the  late  60's.  divides  messages  up  into  small  standard  length  segments  called  packets 
and  sends  these  packets  individually  through  the  network  [Ref.  4:  p.  32]. 

Packet  radio  similarly  sends  messages  in  short  bursts  of  radio  wave  propagation, 
or  packets.  The  ALOHANET.  one  of  the  original  packet  radio  networks,  sends  SO 
characters  of  data  in  one  packet  in  73  milliseconds,  about  1, 10  of  a  second  [Ref.  5:  p. 
203].  The  same  information  sent  over  a  voice  channel  by  a  human  would  take  many 
times  longer. 

The  advances  in  micro  processing  over  the  last  ten  years  have  enabled  the 
electronic  components  of  a  packet  radio  to  be  contained  in  a  hand  held  unit  which 
includes  a  keyboard  and  display  similar  to  a  calculator.   [Ref.  3:  p  .7] 

B.  ADVANTAGES 

The  advantages  of  packet  radio  are  basically  three  fold:  One,  it  provides  mobile 
access  to  computer  facilities.  Two,  it  provides  a  rapid  means  to  communicate  data 
using  very  little  radio  spectrum.  Three,  it  has  a  broadcast  capability  which  allows  a 
sender  to  transmit  a  message  to  multiple  locations  at  one  time  The  following 
paragraphs  detail  these  advantages  and  explain  why  they  are  particularly  appropriate 
for  the  logistic  communications  needs  of  a  Marine  landing  force.   [Ref.  6:  p.  1470] 

1.  Mobility 

The  advantage  of  mobile  access  allows  anyone  with  a  packet  radio  who  is 
within  range  to  access  computer  resources.  There  is  no  need  for  a  special  modem  or 
telephone  lines.  With  a  packet  radio,  whether  in  a  car,  on  a  street,  in  the  mountains  or 
the  desert,  easy  access  is  quickly  available. 
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This  advantage  is  ideally  suited  for  Marine  landing  forces  that  must  be  mobile. 
Hardwire,  telephone-like  communications  are  not  flexible  enough  to  adapt  to  the 
changing  needs  of  a  Marine  landing  force,  but  packet  radio  is  linked  automatically  to 
computer  capabilities.  With  an  omnidirectional  antenna  no  special  installation,  set  up, 
or  alignment  is  required.  All  the  operator  has  to  do  is  turn  the  packet  radio  on  and 
start  kevina  in  data. 

2.  Rapid  Communications 

Logistic  traffic  sent  over  a  voice  channel  does  not  use  the  total  available 
bandwidth.  Much  of  the  time  a  voice  channel  is  available  there  is  no  information  sent. 
This  is  due  to  the  natural  pauses  that  make  speech  intelligible.  Voice  traffic  is 
communicated  at  the  same  rate  as  humans  input  sound.  Assuming  a  9600  bps  data 
rate,  8  bits  per  character,  and  80  characters  per  packet,  it  would  take  640,9600,  or  1  15 
of  a  second,  to  transmit  a  packet.  How  long  would  it  take  for  a  person  to 
communicate  80  characters?  The  potential  for  improvement  in  this  area  is  obvious. 
Packet  radio  makes  good  use  of  a  short  burst  of  data  using  radio  propagation,  thus 
maximizing  radio  spectrum  use.  This  capability  would  be  of  primary  importance  to  a 
communications  officer  who  is  trying  to  satisfy  the  many  communication  needs  of  the 
total  landing  force. 

3.  Broadcast 

In  a  traditional  hardwire  network,  one  message  would  have  to  be  sent  to  every 
addressee  individually.  Packet  radio  on  the  other  hand  enables  the  sender  to  broadcast 
a  message  to  any  number  of  locations  at  the  same  time.  In  view  of  this,  consider  the 
broadcast  capability  applied  to  the  problem  oC  redistribution  as  described  in  the 
previous  chapter.  Let  us  assume  the  support  element  is  divided  up  into  nine  DET's. 
When  a  demand  cannot  be  satisfied  at  one  DET  it  could  simply  be  sent,  in  one 
message,  to  all  the  other  DET's  asking  for  a  redistribution  of  the  needed  item.  If  the 
item  was  available,  a  redistribution  could  be  arranged  immediately. 

Packet  radio  broadcast  capability  can  also  be  used  to  save  time  by  sending 
certain  types  of  requisitions  directly  to  the  source,  while  informing  the  chain  oC 
command  at  the  same  time.  Thus,  the  usual  procedural  delay  would  be  minimized. 
Although  simple  supply  part  requests  could  be  sent  in  this  manner,  certain  other  types 
of  requests  might  require  some  sort  of  approval  message. 
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C.       DISADVANTAGES 

There  are  three  significant  problems  involving  packet  radio:  contention  for  the 
channel,  security,  and  reliability  [Ref.  6:  pp.  1472-1476].  Although  there  are  ways  of 
avoiding  these  problems,  the  tradeoffs  result  in  added  complexity  and  possibly  a 
decrease  in  spectrum  utilization. 

1.  Contention 

Since  there  is  only  one  frequency  normally  available  for  a  packet  radio 
network,  each  member  of  the  network  must  share  this  channel.  If  two  or  more 
members  transmit  packets  at  the  same  time,  a  collision  will  occur  which  usually 
destroys  both  packets.  A  protocol  must  be  established  to  detect  and  avoid  collisions. 
Many  such  protocols  have  been  proposed  that  involve  complicated  queuing  theory. 
Each  of  these  protocols  use  an  acknowledgment  scheme  whereby  the  destination  sends 
back  a  message  to  the  source  indicating  that  it  has  received  the  packet  correctly.  If  the 
source  does  not  receive  an  acknowledgment,  it  retransmits  the  packet  after  a  random 
wait  time. 

2.  Security 

Since  packet  radio  is  a  broadcast  medium,  anyone  within  range  with  a  packet 
radio  and  knowledge  of  the  frequency  being  used  would  be  able  to  listen  to  the 
network  traffic.  More  important  to  military  operations,  if  the  frequency  is  known,  all 
the  enemy  has  to  do  is  send  bogus  packets  (one  right  after  the  other)  to  jam  the 
channel.  Jamming  the  channel  in  such  a  way  will  virtually  shut  down  the  network. 
This  is  obviously  a  critical  problem  to  overcome  when  considering  any  useful  military 
application.  Spread  spectrum  techniques  such  as  a  frequency  hopping  or  a  pseudo 
noise  spread  spectrum  scheme  could  be  used  to  combat  this  security  problem.  While 
both  techniques  can  actually  increase  spectrum  use  by  sharing  frequencies,  they  also 
introduce  complex  synchronization  problems. 

3.  Reliability 

Packet  radio  relies,  after  all.  on  radio  propagation  and  is  prone  to  all  of  the 
same  disadvantages  that  any  radio  network  encounters.  Line  of  sight  links  are  required 
which  make  it  difficult  to  ensure  network  integrity.  Weather  conditions,  time  of  day 
and  unintentional  noise  created  by  such  common  occurances  as  vehicle  ignitions  and  so 
forth,  could  adversely  affect  packet  radio  reliability. 


D.       OTHER  CHARACTERISTICS 

There  are  a  number  of  ways  packet  radios  can  be  employed.  As  with  any 
network,  the  choice  of  a  network  structure  that  provides  the  optimal  service  is  an 
extremely  complex  problem.  If  structured  properly,  however,  a  packet  radio  network 
can  provide  a  number  of  interesting  capabilities.  Some  of  these  capabilities  will  be 
described  in  the  following  paragraphs.  Additionally,  the  discussion  includes  the 
environments  which  are  best  suited  to  take  advantage  of  these  capabilities. 

1.  Repeaters 

Repeaters  are  used  to  extend  the  range  of  packet  radio  networks.  Radio 
packets  can  literally  "hop"  from  one  repeater  to  another,  as  many  times  as  required,  to 
reach  their  destination.  One  interesting  aspect  concerning  repeaters  is  that  the  packet 
pulses  are  reshaped,  retimed  and  retransmitted.  Amplification  not  only  amplifies  the 
message,  but  also  the  accompanying  noise.  Retransmission  eliminates  this  problem  by 
decoding  the  packet  at  each  repeater  and  retransmitting  it,  so  that  the  only  noise 
received  at  the  destination  point  is  that  which  is  picked  up  during  the  last  hop. 

2.  Bucket  Sorting 

One  of  the  most  unique  aspects  of  packet  radio  technology  is  its  broadcast 
ability.  This  concept,  when  applied  to  the  common  search  and  retrieve  problem,  has 
some  interesting  results.  A  particular  application,  referred  to  as  bucket  sorting,  is 
explained  below. 

Bucket  sorting  uses  packet  radio  broadcasting  to  locate  an  item  that  could  be 
recorded  at  any  number  of  locations  or  nodes  that  are  all  within  radio  range  of  each 
other.  When  k  nodes  can  be  accessed  at  the  same  time,  the  search  time  is  reduced  by 
l.k  multiplied  by  the  search  time  without  broadcast  ability.  For  simplicity  of 
explanation,  let  us  say  there  are  16  buckets  and  9  packet  radio  nodes  and  144  items  in 
a  network.  Buckets  are  simply  categories,  or  names,  for  a  group  of  related  items.  All  oi~ 
the  9  packet  radio  nodes  have  one  storage  slot  for  each  of  the  16  buckets.  As  such, 
each  node  can  store  one  item  per  bucket  (all  144  items  can  be  stored  in  a  unique 
node, bucket).  Now,  when  a  particular  item  is  needed,  a  station  first  determines  which 
bucket  the  item  belongs  to,  then  broadcasts  a  request  for  that  item  along  with  its 
bucket  name.  Each  receiving  node  identifies  the  bucket  and  looks  at  the  item  it  has 
stored  in  that  bucket  for  a  match.  If  there  is  a  match,  the  item  record  is  located  from 
144  possible  items  after  only  one  attempt.  Of  course,  this  case  assumes  there  are 
enough  nodes  and  buckets  so  that  each  item  can  be  stored  in  a  unique  node;  bucket. 
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Practically  speaking,  there  probably  would  be  many  items  in  each  node  bucket  but  this 
would  still  substantially  reduce  the  search  time.   [Ref.  7:  p.  177] 

Bucket  sorting  used  with  packet  radio  broadcasting  is  particularly  suited  to 
situations  where  issue  points  are  mobile  and  are  required  to  be  as  close  to  the  customer 
as  possible  i.e.,  many  small  issue  points  or  distributed  warehousing. 
3.  Capture 

When  two  packets  collide  it  is  normally  assumed  that  both  packets  are  lost, 
but  in  many  cases  the  packet  with  the  strongest  received  signal  will  capture  the  channel 
and  be  received  without  error.  The  strongest  packet  is  the  one  that  has  the  strongest 
signal  at  the  destination  and  this  strength  will  depend  on  signal  power  and  distance 
transmitted. 

A  number  of  mathematical  analyses  have  been  conducted  which  attempt  to 
take  advantage  of  this  capture  phenomenon.  By  assigning  nodes  in  groups  of  closely 
located  terminals  and  restricting  each  member  of  a  particular  group  to  a  particular 
maximum  signal  strength,  collisions  can  be  reduced  and  throughput  increased.  The 
idea  is  to  reduce  the  power  of  transmitters  so  that  their  transmissions  can  be  only 
heard  by  their  closest  neighbors.  In  this  way,  the  packets  would  not  interfere  with  the 
rest  of  the  network.  It  is  clear  that  the  fewer  nodes  one  node  can  hear,  the  lower  the 
probability  of  collision.  And  if  a  weak  packet  is  heard  while  a  strong  one  is  being 
received,  then  the  strong  one  will  capture  the  channel.  The  tradeoff  here  is  that  a 
smaller  transmission  range  will  increase  the  number  of  repeaters  required  to  transmit 
from  node  A  to  node  Z.  The  more  repeaters,  the  more  traffic,  and  the  more  possibility 
for  collision. 

The  important  phenomenon  described  herein  is  called  spatial  reuse,  and  was 
studied  in  19S4  by  Kleinrock  and  Nelson  [Ref.  S:  p.  684].  These  two  researchers  tried 
to  answer  the  question:  How  small  should  a  group  of  terminals  be  to  optimize 
throughput  by  taking  advantage  of  capture?  They  found  that,  at  most.  21%  of  the 
terminals  could  share  the  channel  without  interference,  assuming  a  slotted  Aloha 
protocol.  In  other  words,  groups  could  be  numbered  so  that  21%  of  the  terminals 
could  send  a  message  at  the  same  time.  This  translates  into  groups  of  5  terminals  for  a 
network  of  24  nodes.  It  was  estimated  that,  by  properly  taking  advantage  of  capture, 
throughput  could  be  increased  by  as  much  as  25%.  Of  course,  these  results  depended 
heavily  on  many  other  factors  such  as  the  mobility  of  the  nodes  and  frequency  of 
transmissions. 
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4.  Priority  Packets 

In  19S3  Shacham  published  an  article  that  analyzed  the  effect  of  assigning  two 
levels  of  transmission  power  to  two  groups  of  terminals  in  a  packet  radio  network 
[Ref.  9:  p.  253].  Using  capture,  the  group  that  transmitted  at  the  higher  signal  strength 
would  have  a  priority  over  the  other  group  of  terminals.  As  a  result,  a  preferred  access 
scheme  was  created.  This  protocol  provided  prioritized  service  which  led  to  a  higher 
level  of  performance  for  the  priority  group,  while  the  other  group's  performance 
decreased.  The  point  here  is  that  a  priority  scheme  can  be  easily  implemented  in  a 
packet  radio  network  by  simply  adjusting  the  signal  power  of  nodes.  The  difficulty  is  in 
determining  which  group  of  terminals  deserves  a  priority  status.  A  possible  application 
of  this  concept  is  discussed  in  the  following  paragraph. 

The  loss  ot^  an  acknowledgment  packet  is  more  disruptive  to  network 
performance  than  the  loss  of  the  initial  packet.  An  acknowledgment  loss  will  result  in 
a  message  being  unnecessarily  retransmitted,  possibly  more  than  once.  Most  packet 
radio  protocol  analysis  assumes  that  acknowledgements  are  properly  received  over  a 
separate  channel.  It  has  even  been  suggested  that  one  acknowledgement  be  sent  many 
times,  or  at  the  beginning  and  end  of  a  packet  transmission  slot,  to  insure  successful 
reception  [Ref.  10:  p.  684].  But  the  fact  is  that  acknowledgement  traffic  uses  a  small 
amount  of  spectrum,  since  only  a  few  bytes  of  data  are  normally  required.  Dedicating 
a  separate  channel  for  acknowledgments  is.  therefore,  wasteful.  The  question  now  is: 
how  can  we  insure  acknowledgments  are  successfully  received?  One  option  is  to  send 
acknowledgment  traffic  at  a  higher  signal  strength.  This  would,  in  effect,  be  giving 
higher  priority  to  acknowledgment  packets  which  are  more  critical  to  network 
performance. 

5.  Spread  Spectrum 

One  of  the  most  interesting  inovations  in  packet  radio  protocol  research  has 
been  the  application  of  spread  spectrum  techniques  in  dealing  with  the  problem  of 
contention.  Spread  spectrum  not  only  allows  radio  signals  to  be  received  more  reliably 
but  also  offers  special  military  advantages  by  making  it  difficult  for  the  enemy  to  detect 
and  jam  packet  radio  transmissions. 

There  are  basically  two  kinds  of  spread  spectrum  techniques  that  can  be 
applied  to  packet  radio  networks.  These  techniques  are  known  as  pseudo-noise 
modulation  (P\)  and  frequency  hopping  (FH).  Each  technique  can  be  implemented 
individually  or  at  the  same  time  [Ref.  6:  pp.   1473-1476].    Although  conceived  in  the 
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1940's,  recent  technological  advances  have  allowed  these  concepts  to  become  both 
economical  and  practical  for  today's  use  at  the  company  grade  level. 
a.    Pseudo  Noise  Modulation 

PN  modulation  is  a  process  in  which  there  is  a  basic  data  stream  input  by 
the  user.  A  pseudo  random  bit  generator  produces  another  stream  of  data  (l's  and 
O's).  The  data  elements  in  this  stream  are  referred  to  as  chips  which  distinguishes  them 
from  the  original  data  bits.  For  each  data  bit,  a  fixed  number  of  chips  are  generated. 
As  an  example,  let  us  say  4  chips  are  generated  for  each  data  bit.  These  4  chips  are 
modulo  2  added  to  the  associated  data  bit.  which  produces  another  stream  of  data. 
This  stream  is  then  sent  over  the  radio  frequency  at  four  times  the  actual  data  rate  and 
has  the  effect  o[^  spreading  out  the  radio  signal  over  a  larger  bandwidth.  At  the 
receiving  station  the  signals  are  demodulated  and  again  modulo  2  added  with  the  same 
random  synchronous  stream  of  chips  used  at  the  transmitter,  which  reproduces  the 
original  data  stream.  As  long  as  the  same  pseudo  random  chip  generator  code  is  used, 
and  each  node  is  synchronized,  the  proper  information  will  be  demodulated. 

PN  has  the  effect  of  spreading  out  the  signal  bandwidth,  so  that  the  actual 
signal  resembles  little  more  than  white  noise  to  an  unfriendly  observer.  It  produces  a 
low  spectral  profile  which  makes  it  difficult  to  know  when  a  channel  is  being  used. 
Detection,  therefore,  is  prohibitive  as  long  as  the  enemy  does  not  know  the  pseudo 
random  chip  generation  scheme.  At  the  destination  point  the  receiver  can  identify  its 
code  and  filter  out  everything  else  as  noise.  Without  knowing  the  chip  code,  jamming 
is  close  to  impossible  whether  or  not  the  frequency  is  known.  When  received,  the 
jamming  signals  are  spread  just  like  all  other  received  traffic,  however,  since  it  is  not 
coded  properly  the  jamming  is  effectively  treated  like  noise.  The  result  is  that  PN 
modulation  is  able  to  pick  out  friendly  signals  on  the  channel  from  all  other  noise, 
including  both  intentional  noise  and  white  noise. 

As  a  result  of  spread  spectrum  PN  modulation,  any  signal  not  using  the 
correct  pseudo  random  code  is  ignored.  What  does  this  have  to  do  with  packet  radio 
contention  problems?  Consider  the  situation  where  each  user  within  a  radio  range  uses 
a  different  pseudo  code  to  receive  packets  and  each  node  has  knowledge  of  all  the 
other  PN  codes  being  used.  When  one  node  wants  to  send  a  packet  to  another,  it  first 
determines  what  its  code  is,  then  generates  the  code,  modulo  2  adds  it  to  the  data,  and 
transmits  it.  In  this  way  no  collisions  would  occur,  since  other  packets  sent  at  the 
same  time  would  be  usine  a  different  code  and  would  be  filtered  out  as  noise.   The  onlv 


30 


way  a  collision  could  occur  is  if  both  packets  were  sent  to  the  same  node  at  the  same 
time.  In  a  complex  network,  where  each  node  could  transmit  to  every  other  node,  PN 
modulation  would  significantly  reduce  contention.  In  a  star  network  where  every  node 
must  transmit  to  one  central  station,  PN  modulation  would  have  no  effect  on 
contention.  There  is  also  a  limit  to  the  number  of  codes  one  channel  can  cam-.  If  too 
many  nodes  use  the  channel  at  the  same  time  the  heavy  traffic  may  make  it  too 
difficult  to  identify  the  properly  coded  signal. 

PN  modulation  also  combats  the  effects  of  the  multipath  phenomenon 
[Ref.  6:  p.  1472].  Multipath  is  simply  the  echo  effect  of  radio  propagation.  When  a 
radio  signal  is  transmitted,  not  only  the  line  of  sight  direct  route  signal  is  received,  but 
many  reflections  are  also  received  at  short  delay  intervals.  These  reflections  could 
possibly  be  caused  by  a  number  of  surrounding  obstacles  i.e.,  mountains,  trees,  etc. 
Since  reflections  are  received  with  slight  delay,  they  can  cause  fading  or  disruption  of 
the  original  signal.  Matched  filter  and  correlation  techniques  combat  the  problem  of 
multipath.  Matched  filters  attempts  to  filter  out  the  echo  signals  while  correlation 
integrates  all  of  the  signals  and  essentially  takes  the  average  signal  over  a  certain  time 
slot.  As  a  result,  reliability,  which  is  a  problem  in  any  radio  network,  especially  when 
digital  signals  are  being  transmitted,  is  improved  significantly. 
b.    Frequency  hopping 

FH  spread  spectrum  simply  requires  the  sender  and  receiver  to  hop 
synchronously  from  one  frequency  to  another  in  a  pseudo  random  manner  [Ref.  6:  p. 
1475].  Again,  as  long  as  the  pseudo  random  code  is  not  known  by  the  enemy,  there 
will  be  little  chance  of  jamming  or  detecting  transmissions.  One  of  the  biggest 
advantages  of  FH  is  the  ability  to  share  spectrum  channel  capacity.  Instead  of  having 
ten  dedicated  channels  allocated  to  ten  users  that  most  likely  will  not  use  their  channel 
continually,  we  could,  for  example,  have  fifteen  users  share  the  same  ten  channels,  each 
one  using  a  different  FH  code.  Occasionally  there  may  be  collisions,  depending  on 
traffic  intensity,  but  the  potential  for  allowing  more  users  access  to  the  channel  is 
obvious. 

FH  requires  synchronization  but  the  time  slots  are  usually  not  as  short  as 
those  used  for  PN  modulation.  As  the  slot  size  shortens,  the  complexity  and  cost 
increase.  Today,  synchronization  at  a  slow  rate  of  10  or  20  hops  per  second  is  fairly 
simple  and  practical.  Probably  the  most  difficult  obstacle  to  overcome  for  the  FH 
spread  spectrum  technique  is  not  the  synchronization,  but  the  problem  of  adding  new 
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members  to  the  network.  How  does  a  new  member  know  exactly  where  in  the  FH 
algorithm  the  network  is  located?  One  way  to  solve  this  problem  is  to  associate  time 
of  day  with  the  FH  algorithm.  There  are  also  guessing  methods  which  lead  to  the 
correct  hopping  position.  As  long  as  the  basic  FH  algorithm  is  known,  certain 
educated  guesses  can  be  made  which,  after  a  number  of  attempts,  will  position  the  new- 
node's  FH  sequence  properly.  FH  can  also  take  advantage  of  matched  filtering  and 
correlation  to  reduce  the  impact  of  multipath. 

FH  allows  voice  and  data  traffic  to  share  the  same  channel  at  the  same 
time.  Short  packets  of  1  10  oi~  a  second  can  hop  on  voice  channels  at  the  same  time 
the  channel  is  being  actively  used  with  minimal  effects.  The  voice  channel  user  will,  at 
the  most,  experience  a  short  blip  in  the  channel;  and  if  the  packet  broadcast  is  stronger 
than  the  voice  signal,  it  will  capture  the  channel  without  interference  at  the  receiving 
packet  radio.  Different  FH  codes  could  also  be  assigned  to  different  packet  radios  to 
reduce  contention  in  the  same  way  PN  codes  can  be  assigned. 

In  the  short  run,  FH  is  simple  and  easy  to  use  even  though,  after  a  few 
days,  synchronization  may  become  a  problem.  Nevertheless,  it  is  one  of  the  most  cost 
effective  way  of  dealing  with  packet  radio  contention  and  jamming. 
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IV.  DESIGN 

A.  INTRODUCTION 

To  respond  to  the  Marine  Corps  logistic  deficiency  described  in  chapter  two,  a 
packet  radio  network  will  be  proposed  as  a  solution.  In  the  present  chapter  we  will 
begin  to  design  such  a  network.  The  objective  of  the  design  will  be  to  provide  the  user 
with  a  means  to  quickly  communicate  a  logistic  demand  to  both  the  source  and  the 
chain  of  command,  and  to  increase  the  speed  of  local  processing  by  mechanizing 
functions.  In  general,  our  goal  is  to  allow  any  unit  (down  to  the  company  level)  to 
locate  a  source  of  supply  and  or  logistic  support  that  can  satisfy  its  need  by  just  keying 
a  few  characters  onto  a  hand-carried  packet  radio.  The  OS  I  network  model  will  be 
used  to  describe  the  various  features  of  this  network;  and  although  a  great  deal  of  work 
and  experimentation  are  needed  to  adequately  investigate  the  design  details,  we  will  try 
to  develop  a  prototype  to  establish  the  feasibility  of  performing  a  more  technical 
review. 

B.  NODE  PROCESSING  (APPLICATION  LAYER) 

In  this  section,  the  application  layer  of  the  packet  radio  network  will  be 
developed.  We  will  also  assume  a  network  has  already  been  established  and 
concentrate  on  the  processing  requirements  of  a  typical  node  in  the  packet  radio 
network.  It  is  also  assumed  the  topology  of  the  network  is  hierarchical,  reflecting  the 
chain  of  command.  As  such,  each  logistic  request  will  flow  from  one  level  of  command 
to  the  next  level  higher  until  it  ultimately  reaches  the  support  element.  Additionally, 
we  will  assume  that  each  level  of  command  does  possess  some  support  capabilities,  so 
that  a  number  of  logistics  functions  are  decentralized. 

In  order  to  analyze  the  processing  needs  of  a  node  within  a  packet  radio  network 
that  has  been  designed  to  support  the  logistic  communication  of  a  Marine  landing 
force,  structured  analysis  procedures  will  be  utilized.  A  data  flow  diagram  will  indicate 
processing  needs  from  a  user's  point  of  view  while  a  data  dictionary  will  demonstrate 
the  required  information  for  each  type  of  request  and  a  structured  chart  will  break  the 
process  down  into  programmable  modules. 

In  this  section  we  will  consider  the  processing  of  incoming  packets,  not  the 
generation    of   packets.     Functions    concerning    the    generation    of  packets    at    the 


application  and  presentation  layers  include  receiving  keyed  input,  formatting  the  packet 
for  transmission,  and  placing  a  copy  of  the  packet  in  a  pending  response  file.    These 
functions  will  not  be  discussed  in  this  section,  however.    Only  the  functions  of  the 
receiving  node  will  be  examined  in  this  chapter. 
1.  Data  Flow  Diagram 

The  data  flow  diagram  shown  in  Figure  4.1  demonstrates  the  flow  of  data 
from  the  time  a  request  arrives  at  a  node  to  the  time  it  is  completely  processed  through 
that  node.  The  following  paragraphs  will  describe  the  actions  taken  at  each  step  of  the 
data  How  diagram. 

DETERMINE  ACTION  simply  directs  requisitions  to  the  appropriate 
processing  function.  Some  requests  require  review,  since  they  may  be  invalid  or  the 
commander  may  want  to  approve  all  of  a  certain  type  of  demand.  These  requests  are 
then  sent  to  REVIEW.  Other  requisitions  may  not  require  any  review  and  can  be 
passed  immediately  while  still  others  can  be  processed  by  the  node  at  once.  These 
requests  are  sent  to  PASS  and  TRY  TO  SATISFY  AT  ONCE  respectively. 

At  REVIEW,  a  human  judgement  is  made  on  the  validity  of  the  request  based 
on  the  particular  needs  and  situation  at  the  moment.  A  request  may  be  invalidated 
because  it  asks  for  more  than  the  customer  really  needs  i.e.,  the  company  commander 
that  asks  for  a  50  ton  crane  to  load  a  truck  that  can  only  earn.'  2  1  2  tons.  Also,  the 
quantity  requested  may  be  so  great  that  such  an  issue  would  deplete  the  inventory, 
thus  denying  availability  to  another  unit.  If  a  request  is  invalid,  a  reason  is  provided 
and  the  demand  is  sent  to  CANC  where  cancellation  status  is  sent  back  to  the 
customer.  This  cancellation  action  is  also  recorded  in  the  history  file.  If  the  request  is 
valid,  however,  it  is  sent  to  TRY  TO  SATISFY  AT  ONCE  or  PASS,  again  depending 
on  the  judgement  of  the  operator. 

At  TRY  TO  SATISFY  AT  ONCE  the  item  or  service  requested  is  compared 
against  on  hand  stocks  or  capabilities.  If  the  order  can  be  filled,  available  status  is  sent 
back  to  the  customer,  the  requisition  is  recorded,  the  inventory  adjusted,  and 
arrangements  made  to  pick  up  or  deliver  the  item.  If  the  item  is  not  in  stock  (NTS),  it 
is  sent  to  REVIEW.  This  step  is  necessary  in  order  to  check  the  possibility  of  filling 
the  demand  with  a  substitute  item  or  service.  Also,  the  possibility  exists  that  there  is 
some  simple  error  that  may  have  caused  the  NIS  status,  but  was  not  detected  by  the 
system. 
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Figure  4.1     Data  Flow  Diagram. 
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At  PASS,  requests  are  simply  reformatted  so  they  can  be  sent  to  the  next  level 
of  support.   An  entry  is  also  made  in  the  history  file. 

In  order  to  allow  requests  to  flow  through  the  system  described  by  the  data 
flow  diagram  in  Figure  4.1.  logistics  requests  must  be  grouped  in  such  a  way  that  the 
above  decisions  can  be  made  quickly.  Figure  4.2  is  an  initial  data  dictionary  which 
categorizes  different  type  of  logistics  requests  and  lists  the  necessary  information 
required  for  each  type.  They  are  broken  down  into  six  basic  groups,  some  of  which  are 
broken  down  even  further  into  sub-groups. 

The  flow  of  data  at  the  node  level,  as  shown  above,  is  not  a  compex  process. 
It  simply  provides  a  means  to  accept  requests,  search  a  file  for  availability,  and  pass 
status  back  to  the  customer.  With  this  background  in  structured  analysis  we  will  now 
attempt  to  construct  a  system,  using  computer  technology  to  accomplish  some  of  the 
processing  portrayed  in  the  data  flow  diagram. 
2.  Structured  Chart 

Figure  4.3  contains  a  preliminary  structured  chart  for  a  typical  packet  radio 
network  node.  The  DETERMINE  ACTION  module  in  Figure  4.3  has  been  further 
broken  down  in  Figure  4.4  and  TRY  TO  SATISFY  AT  ONCE  and  PROCESS 
REVIEW  in  Figure  4.4  have  been  broken  down  still  further  in  Figure  4.5  and  Figure 
4.6  respectively. 

Reading  Figure  4.3  from  left  to  right,  it  is  assumed  that  a  packet  arrives  at  the 
node  via  the  packet  radio  network.  The  arrival  of  the  packet  initiates  the  GET 
REQUEST  module.  This  module  first  interrupts  any  ongoing  processing.  It  also  pages 
in  the  required  programs  and  performs  error  detection  using  data  dictionary  files  and 
constraints.  This  error  detection  function  checks  for  input  errors,  not  transmission 
errors  which  are  presumed  to  be  checked  by  the  network.  The  RECORD  IN 
HISTORY  module  would  not  be  required  if  error  detection  is  accomplished  at  the 
sender  level. 

At  DETERMINE  ACTION  the  document  identifier  is  read  in  order  to  funnel 
the  request  to  the  proper  module.  This  corresponds  to  DETERMINE  ACTION  in  the 
data  flow  diagram.  DETERMINE  ACTION  can  pass  requests  to:  PROCESS  PASS. 
PROCESS  REVIEW.  PROCESS  TRY  TO  SATISFY  AT  ONCE.  PROCESS 
RESUBMISSION,  PROCESS  RESPONSE  and  PROCESS  INPUT  ERROR.10 


9 Input  errors  checks  could  be  more  efficiently  accomplished  by  the  sending  node 
but  we  will  show  it  here  for  demonstration  purposes. 
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Figure  4.2    Initial  Data  Dictionary. 


37 


' 

MAINTENANCE 

SERVICE 

Document  Identifier 

Priority 

Document  t 

End  Item 

Location 

Description  of  problem 

MOTOR  TRANSPORT 

PASSENGER 

CARGO 

Document  Identifier 

Priority 

Document  Identifier 

Document  f 

Priority 

Number  of  Passenger 

Document  f 

Pick  up  Point 

Cargo  Description 

Destination 

Quantity 

When 

ENGINEER 

Pick  up  Point 

Destination 

When 

EQUIPMENT 

SERVICE 

Document  Identifier 

Priority 

Document  Identifier 

Document  # 

Priority 

Item  Name 

Document  f 

Quantity 

Service  Needed 

Where 

where 

When 

When 

How  Long 

Figure  4.2     Initial  Data  Dictionary. 
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MEDICAL 
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Priority 

Document  I 

Service  Required 
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PARAGRAPH 

SERVICE 

Document  Identifier 

Priority 

Document  t 

Description  of  Need 

Figure  4.2    Initial  Data  Dictionary. 

Flexibility  must  be  built  into  the  system  to  allow  for  an  easy  way  to  redirect 
the  flow  of  different  types  of  requests  at  DETERMINE  ACTION.  As  such,  the 
system  must  quickly  implement  the  wishes  of  the  commanding  officer  who  may,  for 
example  want  to  send  different  types  of  requests  to  REVIEW  at  different  times. 

If  the  demand  is  one  that  is  designated  to  be  passed  at  once,  it  is  passed  as 
quickly  as  possible.  The  F/P/C  code  must  be  set  to  P  (indicates  passing  action  is 
required).  Both  the  request  and  the  P  code  are  then  sent  directly  to  READ  F/P/C 
CODE.  This  particular  function  may  be  performed  by  programming  the  packet  radio 
attached  to  the  terminal  equipment  to  recognize  and  pass  certain  types  of  demands 
before  the  packet  enters  the  node  system  (at  the  transport  layer).  Thus,  the  PUT  IN 
HISTORY  module  is  shown  here.   This  will  save  terminal  equipment  processing  time. 


10PROCESS  RESPONSE  AND  PROCESS  INPUT  ERROR  are  primarily 
primitive  level  functions  (performed  by  the  node  that  initiates  the  packet)  but  are 
shown  here  for  demonstration  purposes. 
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Figure  4.3     Process  Request. 
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Figure  4.4    Determine  Action. 
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Figure  4.5    Try  to  Satisfy  at  Once. 
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Figure  4.6    Process  Review. 
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Requests  that  are  being  resubmitted  are  merely  reformatted  for  submission 
through  the  system.  This  is  done  by  overlaying  card  column  2  with  an  O  and  routing 
the  transaction  back  to  DETERMINE  ACTION. 

If  the  request  is  a  response  to  a  request  made  by  that  node,  the  pending 
response  file  must  be  called  and  the  appropriate  action  taken  (see  Figure  4.4). 
Essentially  the  same  process  occurs  with  input  error  messages. 

If  the  request  requires  review,  it  is  simply  recorded  in  a  special  pending  file 
and  displayed  printed  for  review  (see  Figure  4.6).  The  review  is  performed  by  an 
operator  who  considers  the  current  situation  and  capabilities,  then  makes  a  decision. 
While  this  decision  is  being  made  the  CPU  cannot  remain  in  a  waiting  state,  but  must 
return  to  the  ready  state  so  that  other  arriving  packets  can  be  processed.  Once  the 
decision  is  made  to  fill,  pass  or  cancel,  the  operator  will  call  up  the  pending  file  to  the 
terminal  screen,  set  the  F  P  C  code  and  if  required  place  an  explanation  in  the  remarks 
field.  When  this  is  done  the  request  is  deleted  from  the  pending  file  and  sent  to  READ 
F  P  C.    The  system  must  respond  to  the  operator's  input  interactively. 

If  the  request  is  a  supply  requisition  that  does  not  require  review,  it  is  sent  to 
TRY  TO  SATISFY  AT  ONCE  (see  Figure  4.5).  When  the  request  reaches  this  point, 
a  determination  is  made  (after  reading  the  document  identifier)  to  see  whether  the 
request  is  for  ammo,  medical,  supply,  rations,  fuel,  a  part,  or  a  float  item.  If  the 
request  is  not  for  a  float  item,  it  is  considered  an  inventory  item  and  the  appropriate 
inventory  file  must  be  searched  to  see  if  the  request  can  be  satisfied.  Once  the  file  has 
been  searched  and  a  match  is  found,  the  file  must  be  reduced  by  the  amount  issued  and 
an  issue  slip  printed  out  for  warehouse  personnel  indicating  the  item,  the  location  and 
the  customer.  The  F,  P  C  code  is  then  automatically  set  to  F  without  the  aid  of  an 
operator. 

If  the  item  is  not  in  stock  (NTS),  then  the  request  is  sent  to  PROCESS  NTS. 
This  module  will  record  the  request  in  a  pending  NTS  file  and  display  print  the  request 
just  like  the  REVIEW  module.  Again,  this  review  will  take  some  time,  so  the  CPU 
must  automatically  return  to  the  ready  state.  The  operator  will  then  decide  to  fill  the 
request  with  a  substitute  item,  pass  it  on  to  the  next  source  of  supply  or  cancel  it. 
Once  a  decision  has  been  made  to  pass  or  resubmit  the  request  with  a  substitute  item, 
the  pending  file  is  called.  If  the  request  is  to  be  resubmitted,  then  the  stock  number  or 
NSN  field  is  replaced  with  the  substitute  and  card  column  two  is  set  to  S  which  will 
key  the  request  to  be  sent  back  through  the  system.  If  being  passed  or  cancelled,  the 
F  P  C  code  is  set  to  P  or  C  which  will  send  the  request  to  READ  F  P  C  code. 
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Normally  requests  are  sent  to  a  particular  issue  point  and  the  issue  point 
personnel  respond  to  that  request  by  providing  the  physical  item.  Since  float  items  are 
repair  parts  that,  themselves,  can  be  repaired,  they  cannot  be  issued  in  response  to  a 
mere  request  from  a  customer.  Before  an  issue  can  be  made  the  customer  has  to 
deliver  a  like  unserviceable  to  the  float  warehouse.  However,  it  is  sometimes  possible 
to  quicken  the  maintenance  cycle,  if  it  is  known  for  a  fact,  before  making  the  trip  to 
supply,  that  an  item  is,  or  is  not,  available  at  the  issue  point.  If  it  is  not  available, 
some  other  arrangement  can  be  made  (ordering  the  next  higher  assembly,  for  example) 
without  wasting  the  time  and  effort  required  to  deliver  the  unserviceable.  For  this 
reason,  the  PROCESS  FLOAT  REQUEST  will  respond  to  an  inquiry  with  status,  but 
no  physical  issue  is  made.  The  float  inventory  will  be  searched  and  status  will  be 
provided  by  setting  the  F/P/C  code. 

At  READ  F/P/C  CODE  the  request  is  recorded  in  history,  the  code  is  read 
and  the  request  is  sent  to  the  proper  module.  If  a  request  has  an  F  P  C  code  of  C  then 
a  response  message  is  formed  by  readdressing  and  sending  a  packet  back  to  the 
customer  with  the  document  identifier  in  card  columns  1-3,  a  C  code  in  card  column  4 
the  document  number  in  5-18  and  any  remarks  in  19-80.  If  the  F/P/C  code  is  F  then  a 
response  packet  is  formed  in  a  similar  manner  and  sent  to  the  customer  with  an  F  in 
card  column  4.  If  the  F  PC  code  is  P,  the  packet  is  readdressed  to  the  next  source  of 
supply.   The  P  is  then  deleted. 

Figure  4.7  contains  a  detailed  data  dictionary  of  the  information  necessary  to 
keep  the  user  informed,  as  well  as  to  process  system  data.  Each  request  is  formatted  in 
an  80  card  column  structure.  Since  the  codes  used,  as  well  as  the  SO  card  column 
format,  are  similar  to  those  currently  used  to  process  supply  requests,  little  training 
would  be  necessary.  This  is  an  important  factor  when  considering  a  system  designed 
for  a  user  with  extremely  limited  computer  processing  experience. 

Along  with  the  normal  processing,  there  should  also  be  a  quick  and  easy  way 
to  update  files.  As  items  are  delivered,  they  could  either  be  recorded  on  a  scanner  or 
hand  written  on  a  form  in  the  warehouse.  Increases  to  on  hand  balances,  condition 
code  changes,  and  the  ability  to  add  a  new  entry  (new  stock  number)  to  a  file  would  be 
necessary.  Such  processing  must  be  interactive.  When  ready  to  update,  an  operator 
has  to  be  able  to  call  up  a  file  and  make  the  adjustment  immediately.  A  database 
management  system  like  dBASE  III  could  provide  this  capability.  Additionally,  such  a 
system  could  produce  ad  hoc  reports,  capable  of  answering  almost  any  question 
[Ref.  11:  pp.  101-119]. 
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OTHER  SUPPLY 
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F/P/C  CODE 

A 

5-la 

DOC  * 

A/N 

19-83 

DESCRIB  Of 

NEED  A/N 

MAINTENANCE 

• 

SERVICE 

C/C 

FIELD  NAME 

DATA 

1-3 

DOC  ID 

MOM 

4 

F/P/C  CODE 

A 

5-la 

DOC  < 

A/N 

19 

BLANK 

20-24 

END  ITEM 

A/N 

25 

BLANK 

26-32 

LOCATION 

33-83 

DESCR1B  OF 

PROB  A/N 

MOTOR 

TRANSPORT 
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REDISTRIBUTION  REQUEST 
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ADDRESS  PKT  SUBTRACT 

C/C      FIELD  MAME     DATA 
1-3      DOC  ID  UOS 

4-70      LIST  OF  8  BIT 

UNIT  ID  CODES  * 


A  »  LETTER 

N  *  NUMBER 

A/N  »  COMBINATION  OF  LETTERS  AND  NUMBERS 

*  INDICATES  WILL  REQUIRE  A  CONVERSION  PROGRAM  TO  TRANSLATE  UNI'i 

ID  CODES  TO  8  BIT  NETWORK  UNIT  ID  CODES.   THIS  WILL  ALLOW  MORE 

UNITS  PER  PKT. 


CODES 

ALL  QTY  -  ALLOWANCE  QUANTY 

C/C  -  CARD  COLUMN 

CONDITION  CODE  (COND  CODE)  -  IDENTIFIES  THE  SERVICEABILITY  Of 
ITEM 

A  -  ASSETS  ON  HAND 
M  -  ASSETS  IN  MAINTENANCE 

DATE  -  ALWAYS  JULIAN  DATE 

DOCUMENT  IDENTIFICATION  (DOC  ID) 

AOZ  -  PARTS  REQUEST 

AOX  -  FLOAT  REQUEST 

AOA  -  AMMO  REQUEST 

AOF  -  FUEL  REQUEST 

AOR  -  RATIONS  REQUEST 

AOH  -  MEDICAL  SUPPLY  REQUEST 

COC  -  COMH  CHECK  PKT 

DOD  -  DELETE  PKT 

LOE  -  REQUEST  FOR  ENGINEER  EQUIPMENT 

EOS  -  REQUEST  FOR  ENGINEER  SERVICE 

HOH  -  REQUEST  FOR  MEDICAL  SERVICE 

MOM  -  MAINTENANCE  REQUEST  (CONTACT  TEAM) 

POP  -  REQUEST  FOR  LOGISTIC  SUPPOERT  NOT  CATEGORIZED  ABOVE 

SOY  -  SYNC  PKT 

TOP  -  REQUEST  TO  TRANSPORT  PERSONNEL 

TOC  -  REQUEST  TO  TRANSPORT  CARGO 

UOA  -  ADDRESS  PAKT  ADD 

UOS  -  ADDRESS  PKT  SUBTRACT 
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CHANGE  0  TO  S  IN  C/C  2  TO  RESUBMIT  (OF  DIC) 

CHANGE  0  TO  E  IN  C/C  2  FOR  ERROR  MESSAGE 

CHANGE  0  TO  R  IN  C/C  2  TO  MAKE  A  REDISTRIBUTION  REQUEST 

CHANGE  0  TO  A  IN  C/C  2  TO  ACK 

CHANGE  0  TO  D  IN  C/C  2  TO  MAKE  A  REDISTRIBUTION  DIRECTION 

CHANGE  0  TO  N  IN  C/C  2  FOR  NEGATIVE  ACKNOWLEDGEMENT 

DOCUMENT  NUMBER 

FIRST  5  DIGITS  -  UNIT  IDENTIFICATION  CODE  (USED  CURRENTLY) 
NEXT  4  C/C  DATE 

LAST  5  C/C  SERIAL  NUMBER  TO  INDICATE  THE  NUMBER  OF  REQUESTS  SO 
FAR  THAT  DAY.  THE  FIRST  DIGIT  OF  SERIAL  NUMBER  WILL  UE: 

T  -  MOTOR  TRANSPORT 

E  -  ENGINEER 

M  -  MAINTENANC 

H  -  MEDICAL 

A  -  AMMO 

R  -  RATIONS 

X  -  FLOAT 

F  -  FUEL 

S  -  OTHER  SUPPLY 

P  -  ANY  OTHER 

DODIC  -  6  CHARACTER  CODE  USED  TI  IDENTIFY  AND  STOCK  AMMO 

END  ITEM  NAME  -  PREFER  TAM  NUMBER  FOUND  IN  THE  TABLE  OF 
AUTHORIZED  MATERIAL  OF  MARINE  CORPS 

F/P/C  CODE  -  STATUS  CODE 
F  -  FILLED 

P  -  PASS  TO  NEXT  SOURCE 
C  -  CANCELED 

LOCATION  NUMBER  -  NUMBER  USED  BY  WAREHOUSEMAN  TO  FIND  ITEMS 

LOT  NUMBER  -  NUMBER  IDENTIFY  LIKE  ITEMS  THAT  COME  FROM  THE  SAME 
MANUFACTURE  AT  THE  SAMEN  TIME 

NSN  -  NATION  STOCK  NUMBER  ASSIGNED  TO  ALL  MILITARY  EQUIPMENT  AND 
PARTS. 

PICK  UP/DESTINATION  POINT  -  COORDINATES  OR  DESCRIPTIVE  WORDS 

PRIORITY  (PRI)  -  CODE  FOUND  IN  MILSTRIP  PUBLICATIONS 
01 
02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
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QTY  -  QUANTY 

SUB  NSN  -  SUBSTITUTE  ITEM 

U/I  -  UNIT  OF  ISSUE 


FILES 


ALL  PENDING  FILES  -  80  CHARACTER  REQUEST 

HISTORY  FILE  -  80  CHARACTER  REQUEST  AND  ERROR  CODE  FIELD 
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A  batch  reorder  process  would  also  be  required  that  would  simply  compare  on 
hand  quanties  to  stock  allowance  quanties  and  format  a  reorder  request  for  the 
difference.   There  is  no  need  to  establish  complicated  reordering  criteria  at  this  level.11 

A  follow  up  or  request  modification  scheme,  for  simplicity,  has  not  been 
included  in  the  node  processing  design.  However,  these  additional  functions  could  be 
implemented  by  changing  the  O  in  card  column  2  of  the  original  requisition  to  T  for  a 
follow  up  or  M  for  a  modification.  Once  received  follow  up  and  modification 
transactions  would  be  compared  against  the  history  file  and  the  appropriate  action 
taken.  Follow  ups  would  be  submitted  as  a  request  through  the  node  system  if  no 
match  was  found  in  the  history  file. 

C.       NODE  HARDWARE  REQUIREMENTS 

The  Marine  Corps  has  currently  provided  IBM  Series  1  mini  computers  to  all 
units  down  to  the  battalion  level.  The  Series  1  that  the  Marine  Corps  purchased  is 
small  and  rugged.  It  has  a  memory  capacity  of  128K  RAM.  The  execution  cycle  time 
varies  from  660  to  900  nanoseconds  with  one  channel  available  [Ref.  12:  p.  117]. 
Could  this  computer  accomplish  the  processing  required  for  a  node  in  the  packet  radio 
network  described  previously?  This  possibility  will  be  explored  in  the  following 
paragraphs. 

1.  Terminal  Equipment  Utilization 

Since  each  node  would  have  to  be  ready  to  process  at  all  times,  its  data 
processing  equipment  must  be  dedicated  to  network  applications.  Terminal  equipment 
at  lower  echelons  may  then  be  underused  and  units  may  not  be  able  to  use  their  data 
processing  capabilities  for  other  applications.  However,  software  could  be  provided 
that  would  cause  an  interrupt  of  other  application  programs  and  page  in  network 
programs.  The  Series  1  computers  then  would  not  have  to  be  entirely  dedicated  to  the 
packet  radio  network. 

2.  Processing  Speed 

The  question  of  speed  is  not  of  great  concern  to  the  user.  This  system  is  not 
required  to  be  real-time  but  is  an  inquiry  system  that  can  wait  for  an  answer  involving 
a  human  decision.  The  only  immediate  response  needed  is  one  that  insures  the  packet 
was  transmitted  and  received  properly  which  is  provided  by  the  data  link  layer.  The 
status  response,  indicating  whether  or  not  the  request  was  filled,  could  be  provided 


Allowance  computation  will  not  be  addressed  here. 
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within  five  or  ten  minutes.  This  may  seem  like  a  long  time  in  data  processing  terms 
but  it  is  far  superior  to  the  days  of  delay  currently  experienced. 

It  is  difficult  to  compute  how  long  it  will  take  to  process  a  request  and  provide 
status  back  to  the  customer  without  actually  writing  the  programs  and  without 
knowing  the  programming  language  used.  It  seems  reasonable,  however,  to  assume 
that  the  computer  processing  will  not  take  longer  than  the  required  five  minutes.  The 
greatest  delay,  of  course,  will  be  caused  by  the  operator  making  the  decisions. 

Another  factor  that  must  be  considered  is  the  traffic  density.  Will  queues  of 
packets  develop  at  network  nodes  waiting  for  terminal  equipment  processing?  To 
answer  this  question  we  must  analyze  the  expected  traffic  and  the  service  or  processing 
time.  In  order  to  perform  this  analysis,  we  will  examine  a  "worst  case"  scenario. 
Basing  our  analysis  on  a  ten  hour  day,  then  taking  current  garrison  supply  operations 
and  multiplying  this  by  two  and  one  half  for  combat  operations,  we  can  estimate  the 
number  of  requests  generated  per  minute  for  the  largest  type  landing  force.1"  These 
figures  are  contained  in  Table  2  and  are  developed  for  the  central  node  where  all 
requests  are  sent  if  they  are  not  filled  at  a  lower  echelon.  In  other  words,  only  one 
node  in  the  entire  landing  force  would  actually  be  this  busy.  These  data  do  not  include 
redistribution,  response  and  error  traffic,  however.  What  we  have  done  here  is  to  use 
extremely  high  estimates  to  demonstrate  a  method  for  solving  this  problem  and  to  gain 
a  general  sense  of  the  problem.  Therefore,  it  is  realized  that  more  in-depth  study  is 
required  to  produce  more  precise  estimates. 

There  are  six  routes  that  a  packet  can  take  once  it  arrives  at  the  node  system: 
PASS.  REVIEW  or  TRY  TO  SATISFY  AT  ONCE,  PROCESS  RESPONSE. 
PROCESS  PROCESS  ERROR  MESSAGE  and  PROCESS  RESUBMISSION.  Since 
this  is  the  final  local  source  and  since  all  requests  must  be  processed  through  REVIEW 
before  they  get  to  PASS  at  this  node  we  will  ignore  PASS.  We  will  also  ignore 
PROCESS  RESPONSE  AND  PROCESS  ERROR,  since  these  are  primarily  primitive 
level  functions.13  PROCESS  RESUBMISSION  will  be  ignored  because  this  traffic  is 
expected  to  be  light.  Also,  for  the  sake  of  simplicity,  redistribution  traffic  is  not 
considered.  In  TRY  TO  SATISFY  AT  ONCE,  since  the  parts  inventory  will  be  much 
larger  than  the  other  inventories  and  will  cause  a  longer  search  time,  we  will  treat  parts 


12Fieures     obtained     from     official     Marine     Corps     records     maintained     at 
Headquarters  Marine  Corps  (MAF  total  monthly  demand  rate). 

Functions  performed  by  the  node  that  generates  the  request. 
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TABLE  2 
HIGHEST  REQUEST  RATE  EXPECTED 


Transaction  Type 
Supply  Parts 
Supplv  Float 
Supply  Other 
Supplv  Rations 
Supplv  Fuel 
Supplv  Medical 
Supplv  Ammo 
Maintenance 
Engineer 
Medical 
Paragraph 
Motor  transport 


Number     Minute 

7 

1/3 

1,6 

1/3 

1/3 

16 

1 

1/6 

16 

16 

1/6 

16 

requests  separately  from  the  others.  Now  there  are  three  routes:  REVIEW,  TRY  TO 
SATISFY  AT  ONCE  (PARTS  REQUEST)  and  TRY  TO  SATISFY  AT  ONCE 
(OTHER  SUPPLY  INVENTORY  REQUESTS).  Some  processing  time  constraints 
may  now  be  established  in  terms  of  program  micro  instructions.  Knowing  the  rate  of 
arrival  for  each  possible  route  in  terms  of  one  minute,  or  60  seconds,  we  can  develop 
the  following  formula: 

7P  +  (2  1/3)S  +  (4  1/3)R  <  60 
P,S,R  <  60 
P,S.R  >   l14 

The  P  is  the  maximum  time  required  for  processing  a  part  requisition  and 
seven  per  minute  is  the  maximum  rate  at  which  these  requisitions  will  enter  the  system. 
The  S  is  the  maximum  processing  time  required  for  ammo,  rations,  float,  fuel,  medical, 
and  'supply  other'  requisitions  and  2  1/3  per  minute  is  the  arrival  rate  for  these 
requisitions.  The  R  is  the  maximum  time  for  processing  a  review  type  requisition  and 
from  Table  2  and  5/6  is  the  rate  these  requisitions  will  enter  the  system.   However,  it  is 


Interrupts  will  cause  an  estimated  1  second  delav  regardless  of  program 
processing  time.  At  this  busy  central  node  the  assumption  is  made  that  network 
programs'would  remain  in  memory  and  not  require  paging. 
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estimated  that  50%  of  the  parts  requests  will  be  NIS,  so  3.5  (7/2)  will  have  to  be  added 
to  the  5,6  which  gives  4  1/3  transactions  per  minute  for  R. 

This  formula  is  only  useful  in  the  situation  where  the  arrival  rate  will  never  be 
greater  than  that  shown  in  Table  2  previously.  Thus,  no  queues  will  develop  since  the 
processes  can  accommodate  the  highest  expected  arrival  rate.  P,  S  and  R  could,  of 
course,  be  any  value  less  than  60  and  greater  than  1,  but  let  us  adjust  some  values  to 
get  an  idea  of  the  processing  constraints  described  by  this  formula. 

Let  us  say  P  =  5  seconds,  S  =  3  seconds  and  R  =  4  seconds.  The  result  is 
59  1  3  seconds  and  it  takes  1  second  to  do  interrupts  for  I  O.  Or  put  another  way, 
considering  it  takes  900  nanoseconds  to  execute  a  micro  instruction,  then  each  process 
is  limited  to  4.44,  2.22  and  3.33  million  micro  instructions  respectively. 15 

The  "worst  case"  approach  is  used  to  analyze  this  problem  because  the 
traditional  queuing  model  is  highly  dependent  on  an  average  arrival  time  normally 
based  on  the  poisson  distribution.  In  this  problem  the  average  has  little  meaning,  since 
the  variance  of  the  average  is  extremely  high  and  extremely  dependent  on  the 
environment.  An  unopposed  landing  will  have  a  much  different  requisition  rate  than 
an  opposed  landing,  the  weather  will  be  an  especially  dominating  factor,  etc. 

If  this  speed  does  not  allow  enough  instructions  to  accomplish  the  required 
processing,  there  is  the  possibility  of  using  two  IBM  Series  1  machines  at  this  final 
source  of  supply.  As  packets  arrive  at  this  central  site,  they  would  be  segregated 
immediately  upon  arrival  by  the  packet  radio.  Let  us  say  each  Series  1  was  hardwired 
to  the  packet  radio  and  all  the  P  transactions  were  routed  to  machine  A  and  the  others 
were  routed  to  machine  B.   The  formula  now  is: 

7P  <  60 

(2  1  3)S  +  (4  1  3)R  <  60 

P,S.R  <  60 

P,S.R  >  1 


l5It  is  realized  that  the  instruction  execution  rate  is  dependent  on  many  factors 
but  this  provides  a  rough  estimate  of  the  required  program  size. 
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Now  P  could  be  as  high  as  8.57  seconds  and  S  and  R  could  be  as  high  as  10.5 
and  S.19  seconds  respectively. 

Four  machines  could  also  be  used.  Machine  A  would  process  all  the  S 
transactions.  Another  machine,  machine  B,  could  process  all  the  P  transactions  with  a 
stock  number  (NSN)  above  a  certain  number.  Machine  C  would  accept  all  P 
transactions  with  NSN's  below  a  certain  number  and  machine  D  would  process  all  the 
R  transactions.  Of  course,  the  inventory  would  have  to  be  divided  between  two 
machines,  but  this  could  be  easily  done  and  would  reduce  search  time.  This  would 
increase  P  to  a  maximum  of  17.14  seconds.  It  would  also  require  more  from  the  packet 
radio,  requiring  it  to  read  and  discriminate  the  first  digit  of  the  NSN,  which  would  not 
be  a  complex  task.  These  time  constraints,  subtracting  one  second  for  interrupts, 
would  allow  27.  14,  and  IS  million  micro  instructions  for  S,  R,  and  P  type  transactions 
respectively.  These  figures  seem  to  be  within  limits  for  this  relatively  simple 
programming  task  and  extra  minicomputers  are  available  in  the  Marine  Corps 
inventor}'  for  this  busy  central  node. 

The  IBM  4341  DFASC  could  be  used  as  a  back  up  to  increase  processing 
speed.  Although  the  IBM  4341  is  much  faster,  the  logistic  network  probably  could  not 
expect  help  from  the  DFASC,  since  it  has  already  been  assigned  a  number  of  other 
tasks.  However,  it  is  available  for  use  during  a  critical  situation  and  should  be 
prepared  to  back  up  the  logistic  network  on  short  notice. 

Also,  by  decentralizing  support  (providing  it  closer  to  the  customer),  more 
demands  would  be  filled  at  a  lower  level  lessening  the  load  on  the  central  node. 
Restock  or  replenishment  requisitions,  which  eventually  result  from  issues  done  at  a 
lower  echelon,  would  be  batch  processed  and  sent  to  the  central  node  during  a  slow 
period  at  night.  This  would  reduce  the  packet  arrival  rate,  which  would  decrease  the 
probability  of  an  explosive  queue  problem.  Decentralization,  however,  will  increase  the 
amount  of  redistribution  requests.  Because  a  redistribution  response  is  required  from 
each  individual  source,  this  processing  will  take  time  away  from  normal  traffic.  The 
disadvantages  of  decentralization,  therefore,  may  outweigh  the  advantages. 
3.  Memory 

Memory  is  another  important  consideration.  The  Series  1  has  only  12SK  of 
RAM  memory.  If  a  dBASE  III  program  was  used  it  could  not  fit  on  a  128K  machine. 
dBASE  III  requires  256K  of  memory,  which  means  another  solution  would  be 
necessary  [Ref.  11:  p.   197].    Perhaps  a  simple  direct  access  file  using  links  could  be 
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programmed  or  bought  off  the  shelf,  or  the  Series  1  memory  could  be  expanded  to 
process  the  database.  Another  option  is  to  write  the  proper  software  that  would 
implement  a  virtual  memory.  Additionally  it  is  estimated  that  about  20,000  inventory 
records  would  be  maintained  by  a  MAF.  However,  these  records  could  be  distributed 
to  many  issue  points  and  computers  so  that  no  more  than  2,000  records  would  be 
maintained  on  any  one  computer. 

The  Marine  Corps  is  contemplating    the  purchase  of  Zenith  Z248  computers 
as  replacements  for  the  Series  l's.    This  machine  has  512K  of  memory  and  can  run 
dBASE  III.    The  Z248  could  also  cope  with  the  demands  of  this  logistic  packet  radio 
system  and  probably  process  demands  quicker  than  the  Series  l.16 
4.  Interrupt  Architecture 

The  interrupt  structure  is  another  important  consideration  of  a  packet  radio. 
For  example,  the  ALOHANET  is  an  interactive  real-time  system.  Developed  at  the 
University  of  Hawaii,  the  ALOHANET  linked  terminals  to  an  IBM  360  via  an  HP 
2100  front  end  computer  from  geographically  distant  areas  [Ref.  5:  p.  203].  The  same 
type  of  interrupt  structure  used  in  the  ALOHANET  could  possibly  be  implemented  on 
either  the  Series  1  or  the  Z248. 

D.  SUMMARY 

It  seems  quite  possible  to  implement  the  logistics  system  described  in  this  thesis 
with  the  computers  already  fielded  in  the  Marine  Corps.  An  expanded  memory  and 
some  system  programming  may  be  required  ,  but  this  could  be  less  expensive  than 
trying  to  outfit  the  Marine  Corps  with  a  new  computer.  Additionally  the  cost  of  the 
packet  radio  repeaters  would  be  reduced,  since  the  keyboard  and  display  functions 
could  be  performed  by  the  terminal  equipment.  An  interrupt  and  paging  software 
package  would  also  allow  the  use  of  other  data  processing  applications  during  the  time 
the  processor  waits  for  packets.  While  the  complexities  of  compatibility  require  more 
research,  the  IBM  Series  1  seems  to  be  a  plausible  option. 

E.  NETWORK  DESIGN 

This  section  of  the  chapter  will  address  the  design  issues  related  directly  to  the 
packet  radio  network.  It  will  be  assumed  that  the  nodes  of  the  network  are  designed  in 
accordance   with   the   previous    section.     Such   characteristics   as   topology,    security, 


16Verified  by  phone  conversation  with  Maj.  Robert  Brown  HQMC  Procurement 
Headquarters  Marine  Corps  Procurement,  27  Aug.  19S6 
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packet   structure,   error   checking,   radio   connectivity,   protocol   and   routing   will   he 
described  herein. 

1.  Topology  (Network  Layer) 

Since  there  is  an  established  need  for  the  chain  of  command  to  be  aware  of 
(and  in  some  cases  approve)  logistics  requests,  a  hierarchical  topology  seems  to  be  the 
most  appropriate  for  this  application.  The  only  other  reasonable  choice  for  this 
particular  situation  is  to  centralize  support  and  require  all  nodes  to  request  support 
directly  from  this  central  activity.  There  are,  however,  several  disadvantages  to  this 
star  topology  approach.  First  of  all  it  is  not  desirable  to  centralize  support  in  a 
combat  environment  because  if  the  support  activity  is  destroyed,  all  support  will  be 
lost.  Support  should  be  distributed,  as  much  as  possible,  to  provide  a  more  survivable 
structure.  Since  transportation  is  at  a  premium  during  an  amphibious  landing,  it  is 
important  to  position  support  as  close  to  the  customer  as  possible.  A  hierarchical 
topology  provides  the  capability  to  distribute  support  among  different  layers  of  the 
hierarchy  thereby  providing  logistic  support  close  to  the  customer. 

Another  disadvantage  to  the  star  topology  approach  is  that  reliability  and 
security  are  likely  to  suffer.  In  a  mobile  situation  the  physical  geography  of  a 
particular  location  may  prevent  direct  access  to  the  central  activity.  For  example,  a 
mountainous  or  jungle  area  may  not  allow  line  of  sight  communications.  Later  it  will 
be  shown  that  line  of  sight  communications  are  necessary  for  packet  radio  operations. 
In  order  to  maintain  network  integrity  some  sort  of  repeater  structure  would  probably 
be  required.  It  may  prove  difficult  to  choose  an  appropriate  repeater  structure, 
especially  in  a  dynamic  situation.  On  the  hand,  by  nature,  the  hierarchical  topology 
provides  a  predictable  repeater  structure.  In  case  repeaters  were  not  used,  transmission 
power  would  have  to  be  high  enough  to  reach  the  central  activity;  higher  than  that 
required  by  a  hierarchical  topology  in  order  to  reach  the  next  level  in  the  chain  of 
command.  The  higher  the  transmission  power,  the  greater  the  chances  of  the  enemy 
being  able  to  detect  and  disrupt  the  channel. 

A  hierarchical  topology  also  has  disadvantages.  It  will  increase  the  number  of 
hops  a  packet  must  make  to  arrive  at  its  destination.  As  the  number  of  hops  increase 
the  delay  time  will  be  magnified,  but,  since  the  user  does  not  expect  real-time 
responses,  delay  is  not  a  significant  factor  in  this  situation.  Traffic,  too,  will  increase 
as  a  result  of  multiple  hops;  but  judging  from  an  initial  scan  of  the  expected  maximum 
request  rate  developed  in  the  last  section,  there  seems  to   be  plenty  of  bandwidth 
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available  so  throughput  will  not  sutler  from  the  added  traffic.   This  will  be  discussed  in 
more  detail  when  the  protocol  issue  is  addressed. 

To  briefly  recap  the  hierarchical  approach,  the  deciding  issues  are:  the  need 
for  distributed  logistic  support  for  survivability,  the  need  to  position  support  as  close 
to  the  customer  as  possible,  the  need  for  higher  echelon  approval  and  information,  the 
need  for  a  predictable  repeater  structure,  and  the  reliability  and  security  factors  in  a 
dynamic  environment.  For  these  reasons,  the  hierarchical  topology  is  deemed  most 
appropriate.  Figure  4.S  is  a  hierarchical  diagram  of  a  typical  logistic  network  designed 
to  support  a  MAF. 

2.  Routing  (Network  Layer) 

With  a  hierarchical  topology  the  problem  of  routing  is  taken  care  of 
automatically.  All  traffic  will  flow  smoothly  from  the  lower  to  the  higher  levels  via  a 
set  chain  of  command;  and  higher  levels  will  be  programmed  to  accept  only  the 
packets  of  its  assigned  subordinates.  As  a  result,  no  address  is  required  on  the  packet, 
only  the  sender's  identification  is  needed.  This  structure  simplifies  the  problem  of 
routing  for  packet  radio  networks,  especially  those  that  are  highly  mobile.  Movement 
is  a  problem  for  most  hierarchical  networks  because  a  node's  movement  will  require 
the  node  to  be  assigned  to  different  hierarchical  routes.  But  movement  in  a  military 
operation  is  normally  done  within  a  hierarchical  group.  A  unit  will  nearly  always 
submit  requests  to  the  same  higher  echelon  node,  thus  movement  is  dynamic  while 
routing  is  static.  For  example,  generally,  a  battalion  will  not  be  assigned  to  different 
regiments  during  an  operation.  The  battalion  will  move  a  great  deal  but  it  will  move 
with,  and  not  away  from,  its  regiment. 

In  this  case  the  tradeoff  is  flexibility,  since  two  nodes  on  the  same  level  cannot 
talk  directly  to  each  other.  There  is  no  stated  requirement,  however,  for  two  nodes  on 
the  same  level  to  communicate  logistic  information.  When  logistic  support  is  needed, 
the  proper  way  to  ask  for  it  is  to  send  a  request  to  the  source  and  not  to  your 
neighbor.  Even  if  your  neighbor  has  something  you  need,  it  is  still  possible  to  go  up 
one  level  in  the  chain  of  command  and  request  a  redistribution  of  the  needed  asset. 

The  most  serious  problem  with  this  routing  scheme  is  its  robustness.  If  one 
link  in  the  chain  of  command  is  disabled,  there  is  no  way  to  get  around  that  particular 
link.  As  such,  all  nodes  below  the  disabled  one  are  cut  off  from  higher  levels  of 
support.  Obviously  this  is  an  unacceptable  situation  and  a  procedure  must  be  found 
that  allows  a  packet  to  flow  around  unserviceable  links. 


60 


-   2 

is  1 


<D    O 

X 


Rq 


cc 

LU 

I- 

cc 

< 

o 
o 

< 
ai 

x 

< 


o 

z 


Q. 

O 

CC 


KI^SKig 


BS  mm 


3g5SaB 


Nfci  1W 


KI»W 


•ggi 


Aiddns 


IVJ.NJCJ 


.c   o 

(0    e 

(A 


■o  5 

<  E 
o 
U 


z 
o 

— 

> 

Q 


Figure  4.8    Proposed  MAF  Logistic  Structure. 
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One  approach  to  this  dilemma  may  be  to  use  packet  radio  broadcast 
capabilities  and  send  the  packet  to  all  nodes  within  radio  range  and  ask  them  to  relay 
the  packet  around  the  failed  node.  For  the  time  being,  let  us  call  this  a  distress  packet. 
We  could  accomplish  this  by  placing  a  "one"  in  a  special  bit,  probably  the  first  bit  of 
the  packet.  If  this  bit  was  a  "zero",  then  the  packet  would  be  disregarded,  unless  the 
sender  was  assigned  to  that  node.  However,  if  the  bit  was  a  "one"  then  each  node 
receiving  the  request  would  relay  it  via  its  chain  of  command  to  the  central  support 
activity  (TLOC).  At  this  point,  the  logistic  request  could  be  honored  and  the  TLOC 
would  be  made  aware  of  the  problem.  The  terminal  equipment  could  be  programmed 
to  display  the  sender's  address  within  the  distress  packet  so  that  it  could  be  determined 
which  route  contained  the  break  in  connectivity.  A  trace,  or  communications  check 
packet  could  then  be  initiated  by  the  operator  to  proceed  as  far  as  the  unserviceable 
link  and  report  back,  thus  indicating  the  problem  location.  Action  could  then  be  taken 
to  reorganize  the  logistic  hierarchy  to  allow  those  nodes  that  were  cut  off  to  be 
reassigned  to  other  senior  nodes.  The  procedure  for  reassigning  addresses  will  be 
discussed  in  the  network  control  section. 

Request  packets  flow  up  the  hierarchy,  however,  response  and 
acknowledgment  packets  flow  down  the  hierarchy.  Thus,  in  addition  to  a  distress  bit  a 
routing  bit  is  necessary  which  will  indicate  that  the  request  is  being  sent  to  the  next 
higher  or  the  next  lower  level.  This  will  insure  that  transactions  travel  in  the  proper 
direction  through  the  network. 

In  conclusion,  the  use  of  distress  bits  allows  packets  to  be  routed  via  the  chain 
of  command  to  satisfy  user  needs  for  command  and  control  as  well  as  for  decentralized 
support,  but  it  also  allows  for  flexible  routing  to  improve  robustness. 
3.  Security 

Security  is  an  extremely  important  consideration  for  this  particular 
application;  not  necessarily  because  the  network  is  carrying  classified  data,  but  because 
packet  radio  is  highly  vulnerable  to  jamming. 

As  mentioned  in  Chapter  Three,  there  are  two  ways  to  combat  packet  radio 
security  problems  using  spread  spectrum  techniques.  One  is  PN  modulation  and  the 
other  is  FH.  Both  require  synchronization,  but  PN  is  more  complex  requiring  highly 
sophisticated  radios  which  may  make  the  network  cost  unacceptable.  On  the  other 
hand,  the  synchronization  required  for  FH  can  coincide  with  the  synchronization 
needed  to  implement  the  multiple  access  protocol.    Thus,  the  network  synchronization 
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could  perform  two  functions,  one  for  security  and  the  other  for  network  protocol.  The 
only  added  costs  of  FH  would  then  be  the  cost  of  a  mechanism  installed  in  the  radio  to 
change  frequencies  at  specific  intervals,  plus  the  memory  and  logic  to  implement  the 
FH  algorithm. 

FH  can  still  take  advantage  of  channel  sharing.  As  previously  pointed  out  a 
data  packet  can  use  a  frequency  close  to  the  frequency  used  by  an  analog  voice 
channel  with  minimal  effect  on  voice  communication.  Let  us  say,  for  instance,  that 
there  were  200  voice  channels  and  packet  transmission  time  was  1/10  of  a  second.  This 
would  cause  a  1  10  of  a  second  blip  to  be  heard  on  the  voice  channel  every  20  seconds. 
This  is  assuming  that  the  packet  radio  network  is  using  100%  of  the  available  time 
slots,  which  is  most  improbable,  given  that  input  is  keyed  in  and  there  are.  at  most, 
only  210  nodes  in  this  application.  By  setting  the  frequency  a  little  higher  or  lower 
than  the  voice  analog  channel,  the  impact  would  be  minimized  and  the  packet  would 
be  able  to  capture  the  channel,  insuring  reception  by  the  destination  packet  radio.  As 
a  result  of  this  capture  phenomenon  a  large  number  of  channels  do  not  have  to  be 
allocated  exclusively  for  digital  FH  communication.  In  some  cases  it  may  be  that  no 
unique  frequencies  need  to  be  assigned  to  the  packet  radio  network.  Although  FH 
may  appear  to  waste  a  fair  amount  of  radio  spectrum,  in  reality,  if  employed  properly, 
it  may  save  radio  spectrum. 

As  mentioned  earlier,  other  security  measures  can  also  be  implemented. 
Reducing  the  power  of  transmissions  to  reach  only  the  next  higher  level  of  hierarchy, 
for  example,  leads  to  improved  security.  Keeping  packets  as  <\>  '''■  as  possible  is 
another  security  measure  to  be  considered.  Basically,  all  aspects  of  the  network  should 
contribute  to  reducing  transmission  time  and  transmission  power. 

There  is  also  the  possibility  of  assigning  different  FH  algorithms  to  different 
parts  of  the  hierarchy.  This  would  make  it  even  more  complex  for  the  enemy  to  jam 
the  entire  network.  If  by  chance  the  enemy  was  able  to  decipher  one  FH  scheme  they 
could  only  shut  down  part  of  the  network.  What  happens,  though,  when  a  distress 
packet  is  transmitted  while  different  sections  of  the  landing  force  are  hopping  on 
different  FH  algorithms?  Only  those  nodes  on  the  same  FH  algorithm  will  hear  the 
distress  packet.  This  fact  may  prove  advantageous,  however,  since  one  of  the  problems 
with  a  distress  packet  is  that  every  node  that  hears  it  will  retransmit  the  packet  up 
through  the  chain  of  command.  Essentially  this  results  in  flooding  the  network,  but  if 
only  those  nodes  on  the  same  FH  algorithm  hear  the  distress  packet  then  the  flooding 
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will  be  reduced  by  a  factor  of  the  number  of  FH  algorithms  used.  Let  us  say  that  the 
division,  wing,  and  support  group  are  each  assigned  different  FH  algorithms.  The  use 
of  multiple  FH  algorithms  will  allow  distress  packet  flooding  to  be  limited  to  the  major 
landing  force  elements.1' 

The  structure  now  envisioned  is  one  in  which  the  wing,  the  division,  and  the 
support  group  units  send  packets  in  accordance  with  unique  FH  algorithms.  Once 
received  at  the  major  element  headquarters,  the  packets  are  retransmitted  in 
accordance  with  a  fourth  FH  algorithm  to  the  TLOC.  This  also  allows  the  major 
element  headquarters  to  send  distress  packets. 

The  disadvantage  of  a  multiple  FH  structure  is  that  it  is  less  likely  a  distress 
packet  will  be  heard.  There  is,  however,  one  possibility  that  may  help  to  avoid  this 
distress  packet  problem.  All  the  FH  algorithms  used  by  the  network  could  be  stored  in 
each  node.  If  a  node  does  not  receive  an  acknowledgment  to  a  distress  packet  using  its 
FH  algorithm,  it  could  try  to  send  the  distress  packet  on  one  of  the  other  FH 
algorithms.  Of  course  this  would  require  more  memory  within  the  packet  radio,  but 
storage  capacity  has  become  inexpensive  enough  so  that  this  may  be  a  cost  effective 
option. 

Another  problem  with  multiple  FH  algorithms  in  a  hierarchical  network  is 
that  added  capacity  must  be  placed  at  the  node  where  the  FH  algorithm  initiates.  In 
the  example  described  above,  the  node  at  the  division  headquarters  must  be  able  to 
send  and  receive  in  accordance  with  the  division  FH  algorithm.  It  must  also  be  able  to 
send  and  receive  in  accordance  with  the  FH  algorithm  used  on  the  link  between  the 
major  elements  and  the  TLOC.  The  only  way  this  can  be  accomplished  is  to  position 
two  packet  radios  at  each  of  these  nodes. 

This  scheme  is  ideal  for  a  typical  MAF  landing  force,  providing  a  typical, 
textbook.  MAF  landing  force  is  ever  employed  for  an  actual  operation.  MAF's, 
MAB's  and  MAU's  are  rarely  organized  strictly  by  the  book  and  real  world  constraints 
prevent  perfection.  And,  although  this  scheme  may  seem  logical,  it  may  not  fit  every 
situation.  Flexibility  must  be  provided  to  the  user  that  allows  for  easy  adjustment  of 
the  FH  structure.  Perhaps  one  FH  algorithm  will  suffice.  In  another  situation  five  or 
six  may  be  necessary.  There  is  a  tradeoff  to  consider  in  making  this  decision.  As  the 
number  of  FH  algorithms  increase,  the  amount  of  equipment  and  complexity  required 
at  certain  nodes  would  increase.   On  the  other  hand,  the  more  FH  algorithms  the  more 
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The  major  elements  are  the  division,  wing  and  support  group. 
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difficult  it  will  be  for  the  enemy  to  detect  and  jam  the  network.  Also,  as  will  be 
demonstrated  in  the  next  section,  the  more  FH  algorithms,  the  greater  the  capacity  of 
the  network. 

4.  Multiple  Access  Protocol  (Data  Link.  Layer) 

As  mentioned  previously  the  synchronization  required  by  the  frequency  hop 
algorithms  could  be  used  to  implement  the  network  protocol.  The  traffic  analysis  in 
the  node  processing  section  (see  Table  2)  indicated  an  approximate  maximum  arrival 
rate  of  10  16  packets  even.'  minute  during  the  busiest  period.  This  translates  into 
about  one  packet  every  6  seconds.  Let  us  assume  a  packet  transmission  time  of  110 
of  a  second  and  that  each  packet  must  travel  5  hops,  each  of  which  requires  a  short 
acknowledgment,  a  response  and  an  acknowledgment  to  the  response  with  a 
transmission  time  of  about  1  50  of  a  second.  One  packet,  therefore,  will  use  .8  seconds 
every  6  seconds.  At  this  rate,  about  13.3%  of  the  bandwidth  is  being  used  (assuming 
no  retransmissions  due  to  transmission  errors). 

The  above  data  seems  to  indicate  that  a  simple  unsynchronized  protocol  such 
as  Pure  ALOHA  would  suffice.  However,  we  ought  to  make  use  of  the 
synchronization  provided  by  FH.  Additionally,  the  figures  used  here  are  only  rough 
estimates  and  should  be  treated  as  such.  In  view  of  this,  a  protocol  that  provides  as 
much  throughput  cushion  as  possible  should  be  chosen.  The  added  capacity  of  a 
synchronized  protocol  will  compensate  for  any  arrival  rate  estimation  errors.  For 
security  reasons,  channel  use  should  also  be  kept  to  a  minimum.  Pure  ALOHA,  by 
nature,  will  cause  a  greater  number  of  collisions  than  any  other  protocol  which  means 
channel  use  per  transaction  is  high  and  security  sutlers.  A  network  design  to  support 
a  Marine  landing  force  must  be  highly  mobile.  Pure  ALOHA,  which  was  designed  for 
a  stationary  fixed  environment,  may  be  unpredictable  when  applied  to  a  dynamic 
situation.  Lastly,  there  should  be  room  for  expansion.  In  the  future,  the  network  may 
be  used  to  transmit  different  types  of  data  to  support  other  systems.  The  protocol 
should  anticipate  such  changes  and  at  best  Pure  ALOHA  uses  only  18°o  of  the 
bandwidth.  For  these  reasons  a  more  structured  and  predictable  protocol  may  be 
necessary. 

Slotted  ALOHA,  on  the  other  hand  is  more  structured,  makes  use  of 
synchronization,  and  provides  double  the  capacity  of  Pure  ALOHA.  Flowever,  Slotted 
ALOHA  has  also  been  designed  for  a  stationary  situation,  and  dynamic  movement 
may  decrease  throughput  (in  unpredictable  ways)  especially  in  a  combat  environment. 
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The  fact  that  acknowledgment  traffic  is  not  considered  when  optimal  throughput  is 
computed  makes  the  results  of  this  theoretical  analysis  suspect  for  practical 
applications.  Slotted  ALOHA  also  allows  nodes  to  transmit  at  the  beginning  of  any 
slot,  making  it  doubly  unpredictable.  Furthermore,  collisions  are  still  numerous.  In 
optimal  Slotted  ALOHA  each  packet  is  transmitted  an  average  of  2.7  times  [Ref.  4:  p. 
237].  This  fact  alone  may  cause  a  security  problem.  Although  Slotted  ALOHA  is 
simple  and  inexpensive,  it  may  be  necessary  to  choose  a  protocol  that  will  maintain 
more  control  over  the  network  traffic. 

Time  division  multiplex  or  TDM  may  provide  the  degree  of  control  we  are 
looking  for  in  this  application.  TDM  reserves  specific  time  slots  for  each  member  of 
the  network.  As  a  result,  the  probablity  of  packet  collisions  is  reduced  to  almost  zero. 
Retransmission  of  packets  is  kept  to  a  minimum,  providing  better  security  and  more 
predictability. 

The  problem  with  TDM  is  that  the  more  nodes  there  are  on  the  network,  the 
longer  the  delay  before  transmission.  For  example,  it  is  estimated  that  210  packet 
radios  are  required  to  support  a  MAF.  If  the  packet  transmission  time  was  1  10  of  a 
second,  each  terminal  would  have  an  opportunity  to  transmit  even.'  21  seconds.  If  a 
transmission  error  occured,  then  the  node  would  have  to  wait  another  21  seconds 
before  it  could  retransmit  the  packet.  Twenty  seconds  is  a  long  time  in  network  terms. 
Although  it  probably  will  take  more  than  20  seconds  to  key  in  the  next  request,  there  is 
no  room  for  transmission  error.  The  network  should  be  a  good  deal  faster  than  the 
input  rate  so  the  user  never  has  to  wait  for  the  network  before  submitting  requests. 
Also,  at  higher  echelons  of  the  hierarchy  a  backlog  would  be  created  since  these  nodes 
must  transmit  the  requests  received  from  all  their  subordinates.  How  then  can  this 
time  be  shortened?  Consider  the  FH  scheme  we  alluded  to  previously.  If  there  were 
four  FH  algorithms,  acting  independently,  would  it  not  be  possible  for  each  FH 
grouping  to  share  one  time  slot  simultaneously?  The  TDM  cycle  would  then  be 
reduced  from  210  to  approximately  65  time  slots.    Let  us  examine  this  situation  further. 

It  was  suggested  previously  that  four  FH  algorithms  be  used;  one  each  for  the 
three  major  elements  and  one  for  the  major  element  to  TLOC  link.  The  TDM  cycle 
would  be  as  low  as  four  slots  for  the  major  element  TLOC  link.  One  slot  is  needed  by 
the  TLOC  to  send  acknowledgments  and  responses.  Thus,  the  delay  before 
transmission  on  this  link  would  be  no  more  than  4  10  of  a  second.  Since  these  nodes 
are  the  most  active,  it  is  appropriate  that  they  incur  only  a  short  delay.    Now,  referring 
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to  Figure  4.8  we  see  that  the  division  has  75  packet  radios.  In  order  to  accommodate 
75  packet  radios,  the  TDM  cycle  would  have  to  be  75/10  or  7.5  seconds.  The  group 
with  50  packet  radios  would  have  a  TDM  cycle  of  5  seconds,  and  the  wing  (air 
element)  85  10  or  8.5  seconds. 

To  cut  the  TDM  cycle  even  further,  we  could  use  the  concepts  of  spatial 
reuse.  By  relying  on  the  capture  phenomenon,  spatial  reuse  allows  packet  radios  from 
physically  separated  groups  to  use  the  same  time  slots  as  long  as  transmission  power  is 
minimized.  For  example,  each  regiment  of  the  division  might  be  able  to  share  joint 
time  slots.  If  the  regiments  were  separated  far  enough  to  allow  efficient  use  of  capture 
then  the  division  TDM  cycle  could  be  reduced  to  7.5  3  seconds. 

Let  us  analyze  this  scheme  in  relation  to  the  traffic  estimates  developed  earlier. 
We  stated  previously  that  the  MAF,  as  a  whole,  would  send  at  most  a  request  once 
every  six  seconds.  Divided  evenly  between  each  major  element  we  could  say  that 
individually  the  division,  wing,  and  support  group  send  a  request  even'  18  seconds 
(assuming  the  most  active  conditions).  Even  without  spatial  reuse  there  is  an  18-7.5  or 
a  10.5  second  buffer  between  the  most  active  arrival  rate  expected  for  the  division  and 
the  capabilities  of  the  network.  There  is  a  substantial  13  second  buffer  for  the  support 
group  and  a  9.5  second  buffer  for  the  wing.  It  would  seem  that  TDVI.  used  with  FH 
spread  spectrum,  can  accept  and  process  data  through  the  busiest  nodes  faster  than  the 
highest  expected  request  rate.  Keep  in  mind  that,  although  more  analysis  is  required, 
this  request  rate  is  two  and  one  half  times  greater  than  the  busiest  garrison  MAF. 

How  many  requests  could  this  system  process?  Since  this  is  a  hierarchical 
topology  where  each  packet  requires  a  retransmission,  an  acknowledgment,  a  response 
to   a  received  packet,   and  a   response  acknowledgment,   only   one   packet  could   be 

i  o 

received  every  four  cycles  by  a  senior  node  from  one  of  its  subordinates.  For 
example,  let  us  assume  a  battalion  headquarters  has  seven  subordinates.  The  senior 
node  (the  battalion)  is  assigned  only  one  slot  in  the  TDM  cycle.  Whenever  it  receives 
a  packet,  it  must  first  retransmit  that  'packet'  up  through  the  hierarchy,  then  send  back 
an  acknowledgment,  and  acknowledge  and  pass  response  traffic.  This  could  take  as 
many  as  four  TDM  cycles  or  30  seconds  which  means  that  each  battalion  could 
process  one  request  every  30  seconds  or  1200  per  a  10  hour  day. 


i  o 

A  senior  node  is  defined  as  the  next   higher  to   a  subordinate  node  in  the 
hierarchy. 
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Since  the  major  element  headquarters  are  equipped  with  a  second  packet  radio 
to  retransmit  packets  on  a  different  FH  frequency,  two  cycles  per  packet  are  needed  to 
perform  the  acknowledgment  and  response  tasks.  If  the  average  number  of  packets 
received  at  these  nodes  exceeds  two  per  cycle,  the  major  element  node  could  develop  an 
explosive  queue.  This  means  the  average  packet  arrival  rate  at  the  wing  headquarters 
cannot  exceed  one  per  every  17  seconds  (2  X  8.5  second  TDM  cycle)  assuming  that  all 
packets  are  received  without  error,  this  would  allow  the  wing  to  submit  a  maximum  of 
2118  packets  per  day.  If  50%  of  the  packets  submitted  were  not  received  correctly  this 
would  cut  the  number  of  unique  packets  to  1059,  1200,  and  1800,  for  the  wing,  division 
and  group,  respectively  for  a  total  of  4059.  These  transmission  rates  are  a  little  short 
of  the  estimated  maximum  estimated  requisition  rate  from  Table  2  (6100  per  day). 
However,  it  is  possible  to  increase  the  maximum  network  capacity  for  a  very  small 
overhead  cost.  Let  us  say  that  we  assign  two  time  slots  to  the  major  element 
headquarters  nodes  per  TDM  cycle,  instead  of  just  one.  This  would  allow  two  packets 
to  be  transmitted  during  every  TDM  cycle  which  would,  in  effect,  double  capacity  at 
the  expense  of  adding  1  10  of  a  second  to  the  TDM  cycle.  The  topic  of  capacity,  as  it 
relates  to  hierarchical  flows,  will  be  addressed  in  the  control  section. 

Another  possible  method  for  increasing  the  capacity  of  the  system  is  to  send 
more  than  one  acknowledgment,  or  response,  in  one  slot.  Later  on  when  the  structure 
of  an  acknowledgement  is  explained,  the  possibility  of  sending  up  to  seven 
acknowledgments  and  six  responses  in  one  time  slot  will  be  demonstrated. 

Still  another  method  used  to  increase  the  capacity  of  the  TDM  protocol  takes 
advantage  of  the  fact  that  request  packets  must  begin  at  the  start  of  a  time  slot.  Once 
a  time  slot  assigned  to  a  subordinate  node  begins,  the  next  higher  echelon  or  senior 
node  could  sense  the  channel.  If  the  slot  was  not  being  used,  the  senior  could  initiate 
the  transmission  of  an  acknowledgment  or  a  response  i.e.,  stealing  an  unused  time  slot. 
Since  acknowledgments  and  responses  are  generally  smaller  than  request  packets,  this 
is  a  reasonable  option.  This  form  of  time  slot  stealing,  however,  should  only  occur 
between  senior  and  subordinate  hierarchical  nodes.  If  the  senior  steals  slots  of  other 
units  not  assigned  to  it,  collisions  may  occur  as  a  result  of  hidden  terminal  problems. 
It  is  assumed  that  the  senior  and  all  subordinates  can  easily  hear  each  other. 
Collisions  involving  acknowledgments  are  most  damaging  to  network  performance, 
therefore  the  practice  of  stealing  other  unassigned  node  slots  for  this  purpose  should  be 
avoided. 
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One  more  procedure  that  could  be  used  to  increase  capacity  is  to  require  a 
terminal  that  has  stopped  transmitting  to  send  a  delete  packet.  The  delete  packet 
would  indicate  to  the  next  higher  echelon  that  it  will  not  transmit  again  for  X  number 
of  minutes.  As  a  result,  that  slot  could  be  used  by  the  senior  node  for  its  own 
purposes.  Additionally,  it  is  estimated  that  it  will  take  at  least  30  seconds  to  input 
transactions  on  a  keyboard.  Programming  this  fact  into  the  senior  node  packet  radio 
would  allow  the  senior  to  use,  for  three  to  four  time  cycles,  the  time  slot  of  a  node 
having  just  completed  a  successful  transmission. 
5.  Synchronization 

It  is  difficult  to  add  and  delete  time  slots  or  members  to  the  TDM  cycle.  Any 
change  in  the  TDM  cycle  during  an  operation  is  hazardous.  All  members  would  have 
to  change  their  respective  places  in  the  TDM  cycle.  The  total  number  of  slots  and 
packet  radios  required  must  be  accounted  for  prior  to  the  time  the  network  initiates 
operations.  By  adding  a  new  member  we  mean  someone  who  was  unaccounted  for 
previously.  This  would  be  a  rare  event  in  a  military  operation  since  everyone  should  be 
accounted  for  before  a  maneuver.  This  is  not  to  say  that  a  unit  cannot  get  on  and  off 
the  network.  As  long  as  there  is  a  time  slice  provided  in  the  TDM  cycle  a  node  can 
transmit  and  cease  transmissions  at  any  time.  In  this  case  deletion  means  being 
dropped  from  the  TDM  cycle,  not  ceasing  transmissions.  Initiating  and  stopping 
transmissions  is  easy,  but  adding  and  deleting  members  is  more  difficult.  Therefore,  the 
case  of  a  node  that  became  inoperable  (but  was  repaired)  and  now  wants  to  begin 
transmitting  again,  is  taken  care  of  since  its  slot  remains  in  the  TDM  cycle  even  while 
it  is  being  repaired. 

In  the  above  paragraph  we  assumed  that  a  node  will  stay  in  synchronization 
even  if  the  packet  radio  is  turned  off  or  becomes  unserviceable.  The  easiest  way  to 
insure  this  is  to  associate  the  FH  algorithm  with  time  of  day  or  with  the  time  the 
operation  commenced.  In  this  way,  each  packet  radio  would  have  an  independent 
clock  that  would  drive  the  FH  and  TDM  synchronization.  The  clock  synchronization 
would  have  to  be  maintained  1  10  or  1/20  second  intervals.  Whenever  a  packet  radio 
was  turned  off  and  then  turned  back  on  again,  it  would  know  where  the  network  was 
in  the  FH  algorithm.  To  insure  that  slippage  did  not  occur,  senior  nodes  could 
transmit  synchronization  packets  at  various  intervals  on  a  predesignated  frequency. 
The  synchronization  packet  would  provide  both  the  proper  time,  in  its  data  element, 
and  the  proper  slot   initiation  point.     Thus,  even  if  a  node  became  totally   out   of 
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synchronization  it  could  get  hack  on  line  by  listening  to  the  special  synchronization 
channel  and  waiting  for  a  synchronization  packet. 

6.  Throughput 

As  as  a  result  of  using  a  TDM  protocol,  a  great  deal  of  spectrum  is  not 
utilized  and  throughput  in  relation  to  available  bandwidth  may  be  poor.  In  fact,  from 
our  initial  estimates,  the  division  can  process  only  one  packet,  transmitted  in  1  10  of  a 
second,  even,'  15  seconds.  In  the  commercial  sector  this  would  be  a  highly  important 
concern,  but  in  a  military  operation  it  is  not  such  an  important  consideration.  As  a 
matter  of  fact,  the  less  the  channel  is  used  the  better,  since  more  use  increases  the 
probably  of  enemy  detection.  Of  course,  the  means  to  increae  capacity  described  in  the 
multiple  access  protocol  section  would  increase  this  throughput  rate  i.e..  slot  stealing 
and  or  adding  extra  slots,  etc.  Throughput  is  also  affected  by  how  the  channel  is  used 
with  FH.  As  stated  previously,  FH  allows  packets  to  be  sent  over,  or  very  close  to. 
analog  voice  frequencies  at  the  same  time  the  voice  channel  is  being  used;  allowing  for 
the  possibility  of  more  than  100%  utilization  of  the  available  spectrum.  Still,  it  is 
important  to  keep  in  mind  that  throughput  does  not  have  the  same  meaning  in  a 
military  context  as  it  does  in  a  commercial  application. 

7.  Acknowledgment  Wait  Time  (Data  Link  Layer) 

The  wait  for  acknowledgment  time  does  not  have  to  be  random  when  using  a 
TDM  protocol.  The  acknowledgment  process  should  be  fast  enough  to  allow 
acknowledgment  prior  to  the  next  scheduled  time  slot.  Thus,  if  the  TDM  cycle  was 
five  seconds,  and  the  acknowledgment  had  not  been  received  within  five  seconds,  the 
packet  would  be  retransmitted  the  next  time  the  node  was  given  the  opportunity  to 
transmit.  This  may  prove  difficult,  however,  if  the  TDM  cycle  is  short  as  in  the  case  of 
the  major  element  to  TLOC  link.  A  node  may  have  to  wait  two  or  three  cycles  before 
retransmitting  on  this  link.  To  insure  reception,  if  the  traffic  will  allow,  it  may  be 
advisable  to  send  acknowledgments  more  than  once  prior  to  the  retransmission  time. 

The  point  here  is  that  retransmissions  do  not  occur  on  a  random  basis.  If  a 
collision  occurs,  and  if  both  members  are  on  different  FH  cycles,  not  only  will  they 
transmit  on  a  different  frequency  the  next  time,  but  they  will  also  transmit  during  a 
different  time  slot.  Since  the  number  of  members  in  each  FH  TDM  cycle  is  different, 
this  requires  different  length  TDM  cycles.    A  problem  may  arise  if  two  packets  of  the 


19Two   cvcles    (7.5    seconds    each)   are    required   for   the   acknowledgment    and 
response,  the  retransmission  being  sent  on  a  different  frequency. 

70 


same   FH  TDM   cycle  collide.     This   problem  would  then  have   to  be  identified  by 
distress  packets  and  resolved  by  the  network  control  functions. 
S.  Character  Representation  (Presentation  Layer) 

The  character  representation  scheme  should  be  minimized  to  use  the  least 
amount  of  spectrum  and  to  increase  transmission  speed.  Keeping  the  transmission 
time  short  will  shorten  the  size  of  the  time  slot,  which  will  reduce  the  TDM  cycle  time. 
A  reduced  TDM  cycle  time  will  have  a  significant  effect  on  all  the  statistics  developed 
previously.  An  analysis  of  the  type  of  data  required  by  the  system  is  necessary  to 
select  the  appropriate  character  representation  scheme. 

By  observing  the  data  dictionary  in  Figure  4.7,  it  can  be  concluded  that  the  26 
letters  and  the  10  digits  are  utilized.  However,  no  distinction  is  made  between  upper 
and  lower  case.  Since  'sentence  type'  remarks  are  possible,  the  basic  punctuation 
marks  are  necessary  (.,?!():;').  Additionally,  a  number  of  special  symbols  are 
required  to  save  space  when  keying  sentences  (#  S  %  4-  =  BLANK.  END  OF 
DATA).  This  adds  up  to:  26  letters,  10  digits,  9  punctuation  marks  and  8  special 
symbols  making  a  total  of  53  characters.  Thus,  a  6  bit  character  representation  would 
be  adequate  for  this  application.  There  also  may  be  a  need  for  one  or  two  control 
characters  to  frame  packets  shorter  than  the  standard  80  data  character  packets.  But 
for  the  standard  data  packet  there  are  specific  formats  which  make  it  easy  to 
distinguish  between  different  card  column  characters.  There  may  be  a  need  for  other 
control  characters  within  the  packet  radio  and  the  terminal  equipment,  but  these  would 
not  require  transmission.  Rather,  they  would  be  for  internal  node  processing.  As  a 
result,  with  a  6  bit  character  representation  scheme  there  are  64  symbols  possible  with 
only  53  being  used.  The  difference  of  1 1  will  become  more  valuable  later  on  when  we 
describe  error  detection  methods. 
9.  Packet  Structure 

The  packet  itself  will  consist  of  three  sections:  the  header,  the  data  and  the 
error  control  section.  Again,  we  will  try  to  minimize  the  data  contained  in  each  section 
for  security  and  efficiency  reasons. 

a.   Header 

The  header  section  normally  contains  the  address,  routing  information  and 
the  packet  number.  Packet  numbers  are  not  required  since  most  transactions  sent  over 
this  network  are  less  than  80  characters  in  length.  The  only  exceptions  may  be 
remarks  that  cannot  fit  into  the  space  provided  or  a  paragraph  type  request  that 
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requires  a  detailed  explanation.  The  need  for  a  message  longer  than  80  characters  is 
not  highly  probable.  It  should,  in  fact,  be  discouraged  since  other  communication 
channels  are  allocated  for  paragraph  type  input.  A  network  to  support  Marine  Corps 
logistic  communication  is  essentially  a  digital  computer-to-computer  channel, 
transmitting  simple  inquiries  and  responses.  The  added  software  complexity  required 
to  reassemble  long  multi-packet  messages  is  not  needed  in  this  situation. 

For  those  unusual  instances  when  multi-packet  messages  are  necessary, 
card  columns  79  and  SO  can  be  used  to  indicate  the  packet  number.  The  operator  at 
the  destination  can  then  manually  assemble  the  message.  If  a  unit  needs  to  send  a 
multi-packet  message  a  0,1  would  be  put  in  card  column  79  and  SO  of  the  first 
transmission.  This  would  indicate  to  the  operator  that  there  would  be  more  to  come. 
This  sequential  procedure  allows  a  unit  to  send  one  message  in  up  to  99  packets  for 
minimum  cost.  The  last  packet  in  a  sequence  would  always  contain  a  99  to  indicate 
end  of  message. 

There  is  no  reason  to  address  the  destination  in  the  header  since  all  routing 
is  fixed  in  a  predetermined  direction  up  through  the  chain  of  command.  In  fact,  we 
could  get  away  with  not  even  addressing  the  sender,  since  the  TDM  cycle  would 
identify  the  sender.  However,  as  a  back  up,  and  as  a  quick  authentication  scheme,  it 
would  be  wise  to  place  a  unit  identification  code  in  the  header.  Since  it  is  estimated 
that  210  packet  radios  are  required  by  the  MAF,  an  eight  bit  identification  code  is 
necessary.  Thus,  a  maximum  of  256  packet  radios  would  be  allowed  on  the  network. 

In  addition  to  the  eight  bit  identification  code  a  one  bit  distress  code  is 
required.  One  routing  information  bit  is  also  necessary  to  insure  packets  are  passed  in 
the  proper  direction  (either  up  or  down  the  hierarchy).  Thus,  the  header  will  contain 
only  ten  bits;  one  distress  bit,  one  routing  bit  and  eight  bits  for  the  unit  identification 
code. 

b.    Data 

The  data  section  of  the  packet  will  contain  only  the  80  characters  of  data 
per  transaction.  Each  character  will  be  six  bits  in  length  for  a  total  of  480  bits.  If  card 
column  80  is  not  used  then  an  'end  of  data'  character  will  be  placed  after  the  last  data 
character.  This  is  done  to  shorten  the  packet  and  to  indicate  that  the  next  bit  will  be 
the  first  of  a  fixed  number  of  error  detection  bits.  The  end  of  data  character  will  be 
placed  in  the  data  section  by  pressing  the  enter  key.20 


20A  method  to  insure  transparency  of  this  character  would  be  required.    Bit 
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The  number  of  bits  in  the  data  field  could  be  shortened  by  making  use  of 
the  fact  that  some  of  the  data  in  the  packet  is  repetitive  and  unnecessary.  The  six 
character  unit  ID  could  be  converted  to  an  eight  bit  unit  identification  code.  Another 
example  is  the  Julian  date.  A  program  module  could  simply  place  the  appropriate  date 
in  this  field  without  requiring  it  to  be  transmitted  from  one  node  to  another.  Similarly 
a  program  module  could  replace  the  36  bit  unit  ID  code  with  an  8  bit  unit 
identification  code.  These  actions  would  be  accomplished  at  the  presentation  and 
session  layers.  It  would  be  advisable,  however,  to  require  that  the  user  continue  to 
input  these  codes  since  it  may  be  difficult  to  adjust  to  such  a  drastic  procedural  change. 
Physically,  the  user  would  input  80  characters  of  data  but  only  70  characters  and  the  8 
bit  unit  identification  code,  or  428  bits,  would  be  transmitted.21  Both  the  unit  ID  and 
the  Julian  date  are  mandatory  entries  for  all  request  packets. 
c.    Error  Control 

The  last  section  of  the  packet  contains  the  error  detection  bits.  Error 
detection  is  extremely  important  in  radio  data  communications.  Radio  is  inherently 
vulnerable  to  many  factors:  weather,  geography  etc.  Military  applications  normally 
require  operations  in  the  most  hostile  environments  possible. 

There  are  two  distinct  error  control  categories:  One  is  transmission  error 
and  the  other  is  input  error.  Transmission  error  is  caused  by  radio  propagation  while 
input  error  is  caused  by  the  user.  We  will  treat  both  categories  separately,  applying 
different  methods  to  each. 

To  begin  with,  input  errors  could  be  detected  prior  to  transmission  by 
having  the  packet  radio  alert  the  user  or  the  terminal  equipment  would  detect  the 
errors  at  the  receiving  end.  Economically  it  would  be  better  to  have  the  packet  radio 
check  the  input  prior  to  transmission.  This  would  save  spectrum  and  increase  security 
and  efficiency. 

In  order  for  the  packet  radio  to  check  input  errors  it  would  have  to  match 
each  field  with  the  data  dictionary.  For  example,  card  column  one  is  the  first  character 
of  the  document  identifier  field.  This  field  has  only  10  possible  entries.  If  the  input  for 
card  column  one  did  not  match  one  o[  the  valid  entries,  an  error  signal  would  be  sent 
to  the  operator.    The  remaining  fields  in  the  request  follow  a  standard  format  which 


stuffing  may  suffice  if  a  bit  synchronous  protocol  was  used. 

To  clarify,  There  are  now  two  8  bit  unit  codes:  one  in  the  header  that  changes 
even-  hop  and  indicates  the  transmitting  node  and  the  other  in  the  data  section  that 
identifies  the  original  requestor. 
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can  be  checked  in  a  similar  manner.  Some  fields,  however,  are  only  limited  by  being 
alpha  or  numeric  and  still  others  have  no  constraints.  This  information  is  contained  in 
the  data  dictionary. 

The  error  checking  described  above  would  demand  a  fair  degree  of  memory 
and  logic  from  the  packet  radio.  However,  with  today's  processing  technology  this 
may  be  feasible.  Additionally,  to  improve  error  checking  the  user  could  personally 
program  some  of  the  request  fields.  A  field  such  as  unit  ID  is  standard  for  each  packet 
radio  and  the  user  could  program  the  input  error  check  to  accept  only  one  particular 
unit  ID. 

There  are  a  number  of  methods  to  detect,  and  in  some  cases  correct, 
transmission  errors.  One  correction  method  involves  the  use  of  a  hamming  code  which 
inserts  parity  bits  into  a  string  of  data  bits.  The  parity  bits  are  placed  in  bit  numbers 
that  are  a  power  of  2.  The  parity  bits  are  included  in  a  sequential  bit  numbering 
scheme.  For  example,  the  bit  stream  1100010  would  have  four  extra  parity  bits 
inserted  and  each  data  bit  would  be  checked  by  at  least  two  parity  bits.  By  a  process 
of  elimination,  this  cross  referencing  detects  and  corrects  errors  [Ref  13:  p.  97].  The 
hamming  code  can  be  used  on  any  length  message.  For  a  message  of  less  than  503  bits 
9  parity  bits  are  necessary  to  perform  error  correction.  One  drawback  to  this  method, 
however,  is  that  only  single  bit  errors  can  be  corrected.  If  more  than  one  bit  is 
transmitted  incorrectly,  then  the  correction  process  will  not  work.  This  may  be  an 
important  constraint  since  errors  in  radio  transmission  may,  for  the  most  part,  occur  in 
groups  of  more  than  one  bit. 

The  longer  the  message,  the  greater  the  chance  of  multiple  errors.  But  if 
the  message  is  short  then  the  overhead  required  for  the  hamming  code  is  proportionally 
higher.  In  the  above  example  we  needed  four  overhead  parity  bits  to  check  seven  data 
bits.  This  additional  overhead  also  increases  the  probablity  of  a  multiple  error,  since 
four  more  bits  are  being  transmitted  for  every  seven  data  bits. 

Another  method  for  checking  errors  is  to  insure  that  each  6  bit  string 
represents  valid  characters.  In  our  character  representation  scheme.  53  out  of  64 
strings  are  used  which  means  11  string  sequences  are  not  valid.  If  one  of  these  invalid 
sequences  is  received,  then  we  can  identify  these  incorrect  characters. 

An  error  detection  check  that  will  detect  almost  any  error  is  the  cyclic 
redundancy  check  (CRC).  This  works  by  dividing  the  transmitted  bit  stream,  which 
can  be  several  thousand  bits  long,  by  a  certain  number.    The  remainder  is  taken  to  16 
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bits  and  then  placed  at  the  end  of  the  packet.  When  received,  the  data  stream  is  again 
divided  by  the  same  number  and  the  16  bit  remainder  is  matched  against  the  16  bits  at 
the  end  of  the  packet.  Usually  if  the  two  numbers  match  there  has  been  no 
transmission  error.  There  is  a  remote  chance,  however,  that  the  remainders  will  still 
match  even  though  there  has  been  a  transmission  error,  but  this  is  a  rare  probability 
[Ref.  4:  p.  128], 

For  the  price  of  16  bits  in  overhead,  it  is  recommended  that  a  CRC  be 
utilized.  Sixteen  bits  will  be  reserved  at  the  end  of  each  transmission  to  perform  a 
CRC  check.  This  will  give  us  a  packet  of  10  +  42S  + 16  =  454  bits.  It  is  also 
recommended  that  remarks  which  are  only  contained  in  specific  positions  not  be 
included  in  the  CRC  check.  Errors  in  these  fields  may  be  better  detected  and  or 
corrected  by  operators. 

With  454  bits  of  data,  what  is  the  most  economical  use  of  the  hamming 
code  method?  The  454  bits  could  be  sliced  into  segments  of  120,120,120,  and  94.  each 
requiring  seven  parity  bits.  This  provides  the  capability  to  make  up  to  four 
corrections,  as  long  as  each  error  falls  into  the  right  segment.  A  more  precise  use  of 
hamming  parity  bits  would  cause  the  packet  and  TDM  cycle  to  be  too  long.  However, 
it  is  presumed  that  most  radio  transmission  errors  will  occur  in  groups  of  more  than 
one  bit.  If  this  is  true,  the  added  overhead  of  using  parity  bits  may  not  be  worth  the 
correction  ability  offered  by  a  hamming  code.  Perhaps,  a  hamming  code  should  be 
used  only  on  specific  and  crucial  fields.  A  more  feasible  allocation  of  the  hamming 
code  technique  follows. 

To  reduce  the  use  of  parity  bits  we  could  allow  four  parity  bits  to  check  the 
header.  Seven  parity  bits  could  be  used  to  check  the  stock  number  field  (13  digits). 
Then  we  could  check  the  16  bit  CRC  with  5  parity  bits.  What  we  have  now  is  16  extra 
parity  bits  for  a  maximum  packet  length  of  470  (Figure  4.9).  If  we  assume  9600  baud, 
which  is  the  rate  used  by  ALOHANET  [Ref.  5:  p.  203],  our  packet  transmission  time 
is:  470  9600,  which  equals  about  49  milliseconds,  a  fraction  under  1  20  of  a  second. " 
As  a  result,  our  system  capacity  has  doubled  because  the  TDM  cycle  has  been  reduced 
bv  one  half.23 


'"If  bit  stuffing  is  used  to  implement  transparency,  a  few  extra  bits  may  be 
required  but  for  this  analysis  a  120  second  transmission  time  will  suffice. 

More  research  may  indicate  that  hamming  parity  is  not  feasible  at  all  for  radio 
transmissions  but  the  above  scheme  provides  us  with  a  maximum  packet  size. 
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DATA  =  SAME  AS  ACKNOWLEDGMENT  +  AN  8  BIT  ORIGINATOR  ADDDRESS 


Figure  4.9    Packet  Structures. 

10.   Acknowledgment  Packet  Structure 

Acknowledgment  packets  will  be  structured  with  only  a  header  and  a  data 
section.  The  header  will  contain  the  destination  address  as  opposed  to  a  request 
packet  that  needs  the  sender's  address.  Previously,  the  receiver  was  always  predefined, 
but  now  the  situation  has  been  reversed  so  that  the  sender  is  known  and  it  is  the 
receiver's  address  that  is  required.    To  keep  the  size  of  the  header  standard  for  every 
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transaction  the  distress  bit  will  always  he  set  to  zero  since  no  acknowledgment  to 
acknowledgment  is  planned.  Acknowledgments  are  assumed  to  be  received  correctly;  if 
not,  the  packet  will  be  retransmitted.  Therefore  the  header  of  an  acknowledgment  will 
consist  often  bits. 

The  actual  data  will  consist  of  the  last  four  characters  of  the  document 
number  (serial  ^)  and  an  acknowledgment  indicator  which  will  be  either  an  N  or  an  A. 
A  is  a  positive  acknowledgment;  N  is  a  negative  acknowledgment.  Thus,  the  data 
section  will  consist  of  30  bits.  There  is  no  need  for  a  CRC  code  because  if  the 
acknowledgment  is  incorrect  there  is  no  easy  way  to  ask  for  a  retransmission. 

When  a  packet  is  transmitted,  a  copy  of  that  packet  is  saved  in  a  pending 
acknowledgment  file.  When  an  acknowledgment  is  received  its  data  section  document 
number  is  compared  against  the  entries  in  the  pending  file  to  find  a  match  with  card 
columns  15- IS.-4  When  the  match  is  found,  the  acknowledgment  indicator  is  checked 
to  determine  if  the  acknowledgment  is  positive  or  negative.  If  positive,  the  packet  is 
erased  from  the  pending  file  and  stored  in  a  history  file.  If  negative,  the  packet  is 
automatically  retransmitted. 

Since  there  is  no  CRC  check  in  the  acknowledgment  we  will  make  the  most 
use  of  the  hamming  code  method.  Since  four  bits  are  always  used  to  check  the  header, 
and  considering  that  as  many  as  eleven  data  bits  can  be  checked  with  four  parity  bits 
then  the  30  data  bits  can  be  divided  into  segments  of  10  data  bits,  each  of  which  are 
checked  by  four  parity  bits.  This  will  produce,  as  shown  in  Figure  4.9,  a  packet  of  56 
bits. 

Since  a  time  slice  is  long  enough  to  transmit  a  request  packet  of  470  bits  we 
could  transmit  as  many  as  eight  acknowledgments  in  one  time  slice.  However,  a 
transparent  "beginning  of  packet"  character  would  be  required  at  the  beginning  and  in 
between  acknowledgments.  This  character  could  be  as  long  as  1 1  bits"  and  still  seven 
acknowledgments  could  fit  in  each  time  slot.  Also,  since  the  acknowledgment  is  so 
small,  it  could  be  sent  after  a  shorter  than  usual  request  packet  or  response.  The  small 
size  of  the  acknowledgment  oilers  many  options.  Ideally,  acknowledgments  should  be 
transmitted  at  a  higher  power  since  they  are  more  critical  to  network  performance.    A 


"Two  packets  with  the  same  serial  number  could  not  be  placed  in  the  pending 
file  at  the  same  time.  One  would  have  to  delav  its  transmission  until  the  first  was 
acknowledged. 

"-This  character  could  also  provide  the  required  radio  svnchronization  for 
unsynchronized  packets. 
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higher  transmission   power  will   allow  capture   of  the  channel,   by  acknowledgment 
packets,  over  any  request  packet. 

11.  Response  Packet  Structure 

Responses  are  required  for  each  request  but  most  responses  contain  only  a 
simple  status  code  i.e.,  filled,  passed  or  cancelled.  Both  filled  and  passed  inventory 
responses  transmit  only  a  status  but  cancelled  responses  may  require  an  explanation. 
Most  service  type  requests  will  also  require  some  explanation  or  coordinating 
instructions.  The  responses  requiring  explanations  will  be  a  full  80  characters  long.  It 
is  estimated  that  50%  of  the  inventory  requests  would  be  fills,  which  is  about  35%  of 
the  total  request  rate.  About  75%  of  the  NIS  (passed  status)  requests  will  not  require 
an  explanation  and  represent  approximately  26%  of  the  total  request  rate.  In  addition, 
it  is  estimated  that  about  20%  of  the  remaining  requests  will  not  require  explanation; 
this  being  about  13%  of  the  total  request  rate.  Thus.  74%  (35  +  26+13)  of  the 
responses  can  be  sent  without  explanation.  These  responses  can  be  structured  like 
acknowledgments  but  instead  of  an  acknowledgment  indicator,  the  F/P/C  code  will  be 
sent.  However,  an  eight  bit  address  must  be  included  in  the  data  section  to  identify  the 
originator  (See  Figure  4.9).  Thus,  six  ot^  these  responses  could  be  transmitted  in  one 
time  slot.  It  still  would  be  advisable  to  display  the  response  in  a  full  80  card  column 
format  in  accordance  with  the  data  dictionary  to  make  the  information  more  readable. 
However,  what  is  actually  transmitted  would  be  only  the  few  essential  characters. 

12.  Physical  Layer 

Keeping  in  mind  the  constraints  of  hamming  coding  (the  ability  to  correct 
only  one  error),  we  should  choose  a  modulation  technique  that  does  not  send  two  or 
more  bits  per  baud.  If  we  did  transmit  in  this  manner  most  of  our  errors  would  be  in 
groups  and  the  effectiveness  of  the  hamming  code  would  be  reduced  further.  A  single 
bit  modulation,  although  slower,  is  much  more  reliable.  A  simple  "phase  shift  keying" 
technique,  for  instance,  would  be  more  than  sufficient  for  this  application.  This  type  of 
modulation  is  easy  to  detect  and  is  less  affected  by  noise  than  AM  and  FM 
modulation. 

Frequencies  can  vary  from  300  MHz  to  30  GHz  for  practical  packet  radio 
usage  (VHF-SHF)  [Ref.  6:  p.  1471].  This  means  line  of  sight  communications  is 
required.  The  higher  the  frequency,  the  less  effect  multipath  has  on  transmissions  but 
the  more  the  need  for  directional  line  of  sight  links.  An  example  would  be  in  the  jungle 
where  high  frequencies  from  1  -  30  GHz  would  prove  ineffective  since  vegetation  would 
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prevent  line  of  sight  communication.  Rain  will  also  aflect  higher  frequencies.  On  the 
other  hand,  higher  frequencies  are  much  harder  for  the  enemy  to  detect  since  they  are 
more  directional. 

As  a  general  rule,  if  the  geography  and  conditions  will  allow,  higher 
frequencies  are  preferred  but  enough  flexibility  has  to  be  built  into  the  radio  itself  to 
allow  the  reception  and  transmission  of  a  variety  of  frequencies.  The  actual  situation 
should  dictate  the  frequency  used,  not  the  hardware.  Unfortunately,  hardware  capable 
of  modulating  over  VHF  to  SHF  ranges  simultaneously  may  be  prohibitively  expensive 
and  bulky. 

F.       NETWORK  CONTROL  (NETWORK  LAYER) 

The  last  section  of  this  chapter  will  examine  the  network  station.  The  network 
station  is  the  node  that  performs  the  central  control  functions  of  a  packet  radio 
network.  The  station  also  acts  as  a  gateway  to  other  networks.  Previously  we  have 
referred  to  the  central  support  activity  or  TLOC.  This  is  the  node  at  the  top  of  the 
hierarchy  to  which  all  requests  flow  if  they  cannot  be  satisfied  at  a  lower  level.  In  view 
of  this  the  TLOC  is  the  logical  place  to  position  the  packet  radio  network  station. 

Control  over  the  network  can  be  either  centralized,  in  which  case  the  station 
performs  most  of  the  network  control  functions,  or  decentralized,  where  the  individual 
nodes  control  the  network.  Decentralized  control  is  more  robust  in  the  sense  that 
network  operations  will  not  cease  if  one  particular  node  is  destroyed.  However, 
centralized  control  is  more  efficient  since  decisions  can  be  made  with  consideration  for 
the  network  as  a  whole.  There  are  a  number  of  tradeoffs  associated  with  the  allocation 
of  control  functions.  In  this  packet  radio  network  we  will  examine  the  various  control 
functions,  determine  if  there  is  a  need  for  control,  and  where  this  control  should  be 
placed. 

1.  Flow  Control 

Flow  control  insures  that  network  equipment  does  not  develop  explosive 
queues.  Flow  control,  for  our  network,  is  actually  performed  by  the  users.  The  keying 
of  data  takes  a  relatively  long  time,  taking  into  consideration  that  most  data  will  be 
entered  by  nontypists  on  a  small  mobile  keyboard.  There  are  only  so  many  requests 
one  user  can  enter  in  a  specific  period  of  time. 
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Let  us  analyze  our  situation  again  with  the  largest  type  of  landing  force,  the 
MAF.  There  are  a  total  of  210  packet  radios;  50  in  the  group,  75  in  the  division  and 
85  in  the  wing.  Let  us  assume  that  it  takes  at  least  30  seconds  to  key  a  request  and 
transmit  a  packet. 

The  structure  of  the  wing  element  was  presented  in  Figure  4.8  previously. 
What  will  happen  if  even'  node  begins  transmitting  continually  i.e.,  even"  30  seconds? 
Let  us  start  at  the  bottom  and  work  up.  If  each  of  the  five  LAAM  Bn.  batteries 
transmit  a  packet  every  30  second,  the  battalion  node  will  receive  one  packet  every  six 
seconds.  The  TDM  cycle  time  is  four  seconds  long.  Keeping  in  mind  that  response 
and  acknowledgment  traffic  can  be  sent  in  any  stolen  time  slot,  if  a  packet  is  received, 
at  the  most  even'  six  seconds,  and  the  LAAM  Bn.  node  can  retransmit  even  four 
seconds,  no  substantial  queue  will  develop.  In  fact,  as  long  as  no  more  than  seven 
units  are  submitting  packets  even  30  seconds  (one  received  per  cycle),  to  any  one 
node,  the  network  will  avoid  congestion.  Neither  of  the  flying  groups  nor  the  HQ 
squadron  have  any  more  than  six  subordinate  units.  The  control  group  has  six 
squadrons  with  the  5  LAAM  batteries  subordinate  for  a  total  of  11.  while  there  are  8 
subordinates  attached  to  the  support  group."  Both  the  control  group  and  the  support 
group  can  steal  slots  from  their  subordinates  that  input  at  the  slow  keyed  rate."'  As  a 
result,  acknowledgment  and  response  traffic  can  be  ignored  for  this  analysis.  However. 
in  both  cases,  an  extra  slot  is  needed  to  prevent  congestion.  With  two  slots  per  cycle 
assigned  to  a  node,  it  can  then  support  up  to  14  subordinates.  The  wing  headquarters 
has  S4  subordinate  units,  but  the  wing  is  a  headquarters  node  which  retransmits 
packets  on  a  separate  radio  and  only  needs  its  slot  to  transmit  acknowledgments  and 
pass  responses.  Acknowledgments  may  be  sent  seven  at  a  time,  or  49  even  30 
seconds.  Also,  slots  can  be  stolen  using  channel  sensing.  Still,  it  may  be  advisable  to 
add  two  or  three  time  slots  to  the  wing  headquarters  for  insurance  purposes. 

The  same  type  of  analysis  can  be  done  for  the  group.  Since  the  TDM  cycle 
time  for  the  group  is  2.5  seconds,  as  long  as  one  unit  has  no  more  than  12  subordinate 
units  there  should  be  no  congestion.  As  Figure  4.8  indicates,  no  unit,  other  than  the 
group  headquarters,  has  more  than  12  subordinates.    Since    the  group  headquarters. 


-bThe  battalion  or  squadron  nodes  are  not  counted  since  requests  from  the 
headquarters  are  submitted  by  the  headquarters  company  squadron  node. 

"Nodes  that  kev  input  use  onlv  one  slot  even.-  30  seconds  while  others  (senior 
nodes)  could  use  their  slot  even  TDM  cycle  since  they  process  the  input  from  many 
users. 
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like  the  wing  headquarters,  retransmits  packets  on  another  radio,  no  delay  should 
result  in  the  group.  However,  an  additional  slot  may  be  added  to  the  group 
headquarters  in  order  to  process  efficiently  any  unexpectedly  high  response  traffic. 

The  division  has  a  TMD  cycle  time  of  3.75  seconds  which  means  a  senior 
node  can  have  no  more  than  eight  subordinates.  Each  infantry  battalion  has  six 
subordinates,  so  no  problem  should  develop  at  this  level.  There  are  19  subordinate 
units  in  each  infantry  regiment,  however,  requiring  each  regimental  node  to  have  two 
extra  slots  to  keep  pace.  Figure  4.10  graphically  demonstrates  this  procedure.  This 
would  mean  that  the  total  number  of  slots  assigned  to  the  TDM  cycle  would  now  be 
81  versus  75.  This  would  create  a  cycle  time  of  4.05  seconds  which  would  mean  that 
only  seven  subordinates  per  slot  could  be  assigned  to  a  node.  The  infantry  regiments 
would  still  be  able  to  support  19  subordinates  since  with  3  time  slots  they  could 
support  21  subordinates.  The  most  congested  node  is  the  division  headquarters,  with 
74  subordinate  nodes  arranged  in  a  narrow  hierarchy.  The  division  headquarters,  like 
the  wing,  would  require  an  additional  two  or  three  slots  also. 

The  TDM  cycle  for  the  TLOC  link  is  4/20  or  .2  seconds  and  it  supports  209 
customers  transmitting  packets  every  30  seconds  which  is  one  packet  every  30/209  or 
approximately  0.15  seconds.  Packets  are  received  only  0.15  seconds  and  must  be 
acknowledged  (and  responded  to)  within  a  time  slot  that  occurs  every  .2  seconds.  If 
another  slot  was  assigned  to  the  TLOC,  congestion  could  be  avoided.  Again,  all 
acknowledgments  and  most  responses  are  small  enough  so  that  many  of  them  can  be 
sent  in  one  time  slot.  In  30  seconds  the  TLOC  could  acknowledge  (30/. 2)  X  7  =  1050 
packets.  But,  will  the  terminal  equipment  be  able  to  handle  one  transaction  even'  0.15 
seconds.  If  the  programs  were  kept  in  memory,  interrupt  and  I  O  time  would  be 
reduced.  This  may  leave  1/10  of  a  second  for  instruction  execution.  At  an  execution 
rate  of  900  nsec,  the  programs  would  be  limited  to  110,000  micro  instructions 

The  first  section  of  this  chapter  indicated  that  processing  time  could  be 
increased  by  connecting  additional  machines  to  the  TLOC  node.  If  three  computers 
were  used  then  the  time  allowed  for  one  transaction  would  be  increased  to  3,10  of  a 
second,  tripling  the  possible  number  of  instructions. 

Printing  equipment  may  pose  a  problem,  however.  Issues  would  require 
location  slips  and  NTS  requests  would  require  printing  or  display  for  review,  but  less 
than  one  line  of  printing  would  be  required  in  each  case.  Issues  would  require  a  13 
digit  stock  number,  a  10  character  location  and  a  14  character  document  number  for  a 
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THREE  CYCLES  FOR ' 
REGEMENTAL  HQ 


Figure  4.10    One  Regiment  of  the  Division  TDM  Cycle. 

total  of  37  characters.  NIS  requests  and  review  type  transactions  would  require  the 
full  80  card  column  transaction,  but  could  be  displayed  on  any  number  of  terminals. 
All  parts  issues,  which  may  amount  to  35%  of  the  transactions,  would  be  spooled  to  a 
printer  in  the  warehouse.  At  an  issue  transaction  rate  of  one  even'  .43  seconds  (.15;. 35 
=  .43),  the  printer  must  be  able  to  print  about  86  characters  per  second.  It  may  be 
necessary,  therefore,  to  maintain  multiple  printers  in  the  warehouse.  Locations  could 
be  sorted  based  on  a  review  of  the  most  significant  location  character  and  sent  to  the 
printer  closest  to  that  location,  thereby  improving  retrieval  time. 
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The  review  requests,  in  this  case,  would  be  sent  to  the  specific  support 
manager.  In  fact,  what  is  envisioned  is  a  TLOC  where  each  major  support  function 
(maintenance,  engineer,  etc.)  has  its  own  terminal.  As  requests  requiring  review  arrive, 
they  would  be  displayed  instantaneously  and  the  support  function  manager  would  take 
the  appropriate  action.  To  keep  pace.  Supply  may  need  four  or  five  displays  and  a 
number  of  printers,  but.  since  this  terminal  equipment  is  already  available,  no  extra 
expense  would  be  incurred.  If  needed,  both  the  equipment  and  the  manpower  are 
available  to  handle  this  extraordinary  request  rate. 

Flow  control  for  this  network  is  basically  maintained  by  the  30  second  input 
constraint  on  the  user.    The  network  processing  nodes,  with  some  minor  adjustments, 
can  accept  input  as  fast  as  the  user  can  provide  it.    As  a  result,  there  is  a  great  deal  of 
leeway  available  in  relation  to  the  problem  of  congestion. 
2.  Network  Integrity 

Another  control  function  is  the  assurance  of  network  integrity.  In  other 
words,  are  all  the  routes  via  the  hierarchy  unobstructed  so  that  each  of  the  nodes  can 
communicate  with  other  nodes  when  the  need  arises? 

When  a  link  in  one  of  the  routes  fails,  a  number  of  distress  packets  will  be 
generated  which  may  cause  Hooding  of  the  network.  Thus,  once  a  distress  packet  is 
received,  the  station  must  immediately  determine  why  the  distress  packet  was  necessary 
by  requesting  a  communications  check  on  the  communication  link.  The 
communications  check  packet  is  sent  to  the  requesting  unit  which  will  inform  even- 
intermediate  unit  that  there  is  a  communications  link  problem.  Each  member,  in  turn, 
will  manually  check  its  own  communication  link.  Once  the  bad  link  is  identified,  a 
response  is  sent  back  to  the  station.  The  operator  of  the  station  will  reassign  the 
affected  subordinate  nodes.  The  unit  responsible  for  the  failed  communications  link 
will  solve  the  problem  by  adjusting  position  or  power,  or  using  an  extra  repeater. 

The  ability  to  quickly  reassign  nodes  in  the  logistic  hierarchy  must  be  a  simple 
and  well  defined  process.  Even  though  this  occurs  infrequently  it  might  be  required  in 
the  early  phases  of  a  landing  because  units  move  ashore  in  stages.  As  a  result,  units 
must  be  quickly  reassigned  to  different  seniors  nodes  to  maintain  logistic  channels. 
Use  of  address  add  and  subtract  packets  facilitates  reassignment  (see  Figure  4.7).  As  a 
matter  of  routine,  this  capability  should  be  available  not  only  at  the  station  but  at  all 
senior  nodes.  This  would  allow  a  field  commander  to  deploy  units  in  any  manner  he 
deemed  appropriate  without  concern  for  logistic  channels.    Of  course,  if  such  action  is 
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taken,  it  would  be  advisable  to  inform  the  station.  Senior  nodes  would  send  address 
add  packets  containing  up  to  50  addresses  in  order  to  reassign  units  to  another  senior 
subordinate.  An  example  of  this  is  when  a  regiment  sends  an  address  add  packet  to 
add  a  company  from  one  battalion  to  another  battalion.  These  packets  would 
automatically  update  the  receiving  packet  radio  program  that  checks  headers  to 
identify  those  packets  it  must  process. 
3.  Other  Control  Functions 

There  are  a  number  of  other  control  functions  but  most  are,  by  nature,  part  of 
the  network  framework.  Throughput  control  is  fixed  by  the  TDM  protocol  while 
security  is  insured  by  the  FH  algorithm.  Error  control  is  conducted  by  CRC  checks 
and  hamming  coding.  Therefore,  the  control  functions  of  the  network  are  for  the  most 
part  built  into  the  network  structure.  The  station  may  have  to  react  to  an  increase  in 
traffic  by  adding  more  processors  or  printers  but  the  only  additional  functions 
performed  by  the  station  are  redistribution  and  interfacing.  Otherwise,  the  station  acts 
very  much  like  any  another  node.  The  data  flow  diagram  and  structured  chart  drawn 
for  the  nodes  could  be  applied  to  the  station  with  a  few  modifications  such  as  those 
relating  to  redistribution  and  network  interfacing. 

a.    Redistribution 

The  redistribution  function  processes  NIS  supply  requests  that  have  a 
potential  for  redistribution.  Each  NIS  request  Stock  number  is  checked  against  a  file, 
containing  the  allowances  and  on-hand  values,  for  all  the  issue  points  in  the  battle 
zone."  If  a  match  is  found,  an  X  is  placed  in  card  column  four  to  indicate  that  the 
item  is  a  redistribution  candidate.  Upon  review,  each  redistribution  candidate  is  first 
validated  for  the  correct  stock  number  by  a  supply  clerk.  If  valid,  a  special  broadcast 
request  is  used  to  inform  all  the  other  issue  points  on  the  battlefield.  A  copy  is  then 
placed  in  a  pending  redistribution  file.  Each  issue  point  checks  to  see  if  the  item  is 
available  and  either  a  positive  or  negative  response  is  then  sent  back  to  the  station.  If 
a  positive  response  is  received,  the  response  is  displayed  and  a  redistribution  direction 
packet  is  transmitted.  The  operator  forms  and  transmits  a  redistribution  direction 
packet  by  placing  a  D  in  card  column  two  of  the  response  which  keys  a  process  that 
performs  this  action. 


"8This  file  would  require  batch  updating  every  three  or  four  days. 
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b.    Interface  Function 

If  a  redistribution  candidate  was  not  available  at  any  of  the  issue  points. 
the  demand  must  be  reformatted  into  a  SASSY"  standard  supply  document.  This  is 
accomplished  by  sending  the  request  to  READ  F/P/C  code  with  a  P  in  card  column 
four  at  the  station.  This  document  must  then  be  placed  into  the  pending  SASSY  file. 
Prior  to  the  time  a  SASSY  update  is  run,  this  file  must  be  dumped  to  a  disk  and  input 
into  the  SASSY  cycle.  SASSY  will  reformat  the  request  for  submission  into 
AL'TODIN.  If  a  DFASC  is  present  the  disk,  could  be  sent  by  courier,  otherwise  the 
information  on  the  disk  must  be  transmitted  via  the  supporting  message  center  to  the 
closest  garrison  SMLV  This  action  would  enable  the  station  to  perform  a  gateway 
function  by  allowing  certain  transactions  to  be  accepted  by  other  networks  and 
systems. 

There  are  two  advantages  to  this  procedure:  One,  it  allows  updated  SASSY 
files  and  records  to  be  maintained.  Two,  it  takes  advantage  of  SASSY's  ability  to 
access  the  numerous  large  files  that  are  required  to  reformat  demands  for  AL'TODIN 
input.  For  instance,  each  stock  number  must  be  identified  with  a  DOD  source  of 
supply.   Thus,  a  file  containing  every  military  stock  number  must  be  accessed. 

G.       NETWORK  HARDWARE 

There  are  three  types  of  packet  radios  required  by  this  network  which  include 
"stand  alone"  packet  radios,  "simple  repeaters"  and  "attached  repeaters".  For  our 
purposes  we  will  define  "stand  alone"  packet  radios  as  those  that  do  not  require 
terminal  equipment  to  accept  keyed  and,  or  display  data.  These  particular  packet 
radios  contain  a  built-in  keyboard,  a  display  and  a  power  pack  which  permits  operation 
anywhere  within  radio  range.  The  "simple  repeaters"  are  packet  radios  that  do  not 
have  a  built-in  keyboard  or  display  and  do  not  interface  with  terminal  equipment. 
They  simply  pass  packets.  The  "attached  repeaters"  do  interface  with  terminal 
equipment  but  do  not  have  a  keyboard  or  display. 

In  our  network,  the  "stand  alone"  packet  radios  would  be  owned  by  the  primitive 
level  (company/section)  nodes.  All  other  nodes  would  maintain  "attached  repeaters". 
"Simple  repeaters"  would  be  maintained  by  the  major  element  headquarters  and  would 
be  used  whenever  a  connectivity  problem  arose.   Although  living  squadrons  in  the  wing 


SASSY  is  the  Vlarine  Corps  standard  automated  supply  system. 

30The  SMU  is  the  SASSY  Management  Unit  that  is  the  issue  point's  source  of 
supply  and  gaters  SASSY  input  and  distributes  output. 
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are  at  the  primitive  or  packet  initiation  level,  they  already  have  their  own  IBM  Series  I 
and  would  not  require  a  "stand  alone"  packet  radio. 

A  packet  radio  is  made  up  of  two  parts:  a  digital  section  and  a  radio  section. 
The  radio  section  is  a  common  radio  not  unlike  any  other  radio  used  for  voice 
communication  that  transmits  and  receives  analog  radio  waves.  It  does,  however, 
accomplish  a  digital-to-analog  conversion,  taking  computer  binary  signals  and 
translating  them  into  an  analog  form  through  modulation.    [Ref.  3:  p.  2] 

1.  Radio  Section 

Reliability  is  of  particular  importance  in  packet  radio  networks.  Voice 
communication  can  tolerate  a  degree  of  disturbance  and  interference,  but  computer 
transmissions  cannot.  One  bit  of  data  transmitted  incorrectly  could  have  disastrous 
consequences.  As  a  result,  packet  radios  must  provide  reliable  transmissions.  The  use 
of  matched  filtering  and  correlation  techniques  to  combat  multipath  is  a  desired 
method  for  reducing  transmission  errors.  The  choice  of  simple  and  reliable  modulation 
techniques  would  also  be  prudent.  Omnidirectional  antennas  to  facilitate  mobile 
operations  are  usually  required. 

2.  Digital  Section 

The  digital  section  of  the  packet  radio  performs  all  of  the  required  processing 
to  implement  the  network  protocol.  Synchronization  to  120  of  a  section  is  necessary. 
Also,  sufficient  memory  is  required  to  maintain  the  programmable  functions  i.e.,  input 
error  checking  and  communication  programs  to  interface  with  an  attached  device. 

Preamble  detection  is  an  important  option  that  allows  authentication  and 
identification.  Thus,  each  packet  radio  within  range  need  only  read  the  first  nine  data 
bits  to  determine  if  it  should  accept  the  rest  of  the  packet. 

A  certain  degree  of  buffering  is  needed  for  the  pending  file  .  This  memory 
requirement  is  small  for  "stand  alone"  packet  radios  considering  the  fact  that  packets 
are  sent  once  even-  30  seconds.  "Attached  repeaters"  may  require  more  buffer  storage 
since  they  may  be  transmitting  many  times  during  a  TDM  cycle.  Storage  is  also 
needed  for  a  pending  response  file  which  must  maintain  20-30  documents,  but  it  is 
necessary  only  for  the  "stand  alone"  packet  radios. 

In  order  to  accomplish  hand  carried  packet  radio  operations,  a  built-in  key 
board  and  display  are  necessary.  This  is  a  difficult  feat  due  to  the  size  constraints  on 
the  keyboard.  However,  the  actual  keys  should  not  be  too  small  as  to  adversly  affect 
the  error  rate.    Calculator  type  spacing  would  not  be  recommended  because  this  key 
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size  is  susceptible  to  errors  Technological  constraints  also  limit  the  size  of  displayed 
characters  [Ref.  3:  p.  111].   A  possible  compromise  is  drawn  to  scale  in  Figure  4.11. 

Another  important  characteristic  of  the  packet  radio  is  its  power  source. 
Since  mobility  is  required  for  "stand  alone"  and  "simple  repeaters"  battery  power  is 
necessary.  "Attached  repeaters"  can  rely  on  a  generator  for  power  using  the  same 
generator  that  now  powers  the  IBM  Series  1.  Battery  power  has  always  been  a  rare 
and  valuable  commodity  in  the  field  requiring  packet  radio  architecture  to  be  power 
conservative.  One  prudent  option  is  to  reduce  power  during  listening  times  and  to  shut 
down  the  radio  at  other  predetermined  times.  The  ability  to  receive  power  from  both  a 
generator  and  a  battery  so  as  to  make  use  of  other  available  sources  of  energy  is 
desired. 

Appendices  B  and  C  contains  a  list  of  network  hardware  specifications  as  well 
as  a  model  describing  the  network  layers  a  packet  travels  when  being  sent  through  the 
network. 
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Figure  4.11     Stand  Alone  Packet  Radio  Model. 
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V.  CONCLUSION 

In  conclusion  we  have  designed  a  prototype  network  that  appears  to  solve  the 
problems  that  were  originally  identified  by  the  user.  The  following  is  a  synopsis  o[  the 
user  problems  and  the  solutions  provided  by  the  packet  radio  network. 

A.       PROBLEMS  AND  SOLUTIONS 

1.  Communication 

Communication  of  logistic  requests  are  now  electronic  versus  the  standard 
courier.  Access  to  any  support  agency  on  the  battlefield  or  aboard  ship  by  a  company 
level  command  can  now  be  accomplished  in  seconds  as  opposed  to  days.  This  access 
can  be  obtained  with  little,  if  any,  affect  on  command  and  control  channels. 

2.  Transportation 

The  demand  for  transportation  is  reduced  because  we  can  position  support 
closer  to  the  customer  in  a  distributed  manner  without  the  usual  problems  associated 
with  redistribution.  Supplies  can  also  remain  aboard  ship  longer  since  customers  can 
now  easily  communicate  logistic  requests  to  support  functions  afloat.  Thus, 
transportation  is  not  required  to  shuttle  the  whole  supply  issue  point  ashore  in  the 
early  stages  when  the  demand  for  transportation  is  greatest.  Only  those  items 
requested  need  to  be  sent  ashore. 

3.  Procedures 

The  procedure  problem  is  not  as  acute  since  requests  can  be  rapidly  relayed 
from  one  level  of  command  to  another.  Therefore,  procedural  delay  is  not 
substantially  increased  and  the  higher  levels  of  command  are  kept  informed  of  even  the 
simplest  supply  requests.  As  such.  S4?1  logistic  officers  can  now  become  active  in  the 
support  function  during  an  operation  instead  of  acting  as  bureaucratic  go-betweens. 

4.  Node  Processing 

Much  of  the  node  processing  is  done  automatically.  The  only  time  an 
individual  gets  involved  in  the  process  is  when  the  warehouseman  receives  a  location 
slip  or  the  demand  cannot  be  satisfied  by  on  hand  stocks.   The  fact  that  the  operator  is 


The  S4  officer  is  the  logistic  officer  for  units  down  to  the  battalion  level. 
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involved    only   when    a   judgement    is    required,    and    that    automatic    decisions    are 
mechanized,  is  an  appropriate  approach  to  data  management.    As  a  result,  processes 
that  used  to  take  minutes  now  take  seconds. 
5.  Number  of  Steps  Involved 

There  are  fewer  steps  involved  and  most  of  them  are  performed  faster. 
Previously  all  supply  part  requests  were  researched  prior  to  a  stock  check,  which  was  a 
time  consuming  task.  Now.  prior  to  any  research,  stock  checks  are  done  automatically. 
As  a  result,  correct  requests  are  processed  immediately  while  only  those  that  are  not 
available  or  are  incorrect  are  researched. 

B.       ADVANTAGES 

1.  Capacity 

We  now  have  the  outline  of  a  logistic  support  network  that  can  process  ideally 
205,200  requests  in  a  10  hour  day  (every  primitive  node-"  transmitting  one  packet 
every  30  seconds  without  error);  about  33.6  times  faster  than  the  estimated  maximum 
request  rate  of  6100  per  day.  This  provides  plenty  of  leeway  for  incorrect  estimates  or 
unforeseen  problems  that  may  occur. 

2.  Expansion 

With  adjustments  to  the  application  layer  there  is  abundant  room  for 
expansion.  Other  systems  that  may  take  advantage  of  this  network  are:  personnel 
reporting,  maintenance  status  reporting  and  fire  coordination. 

3.  Speed 

Speed  and  asset  visibility  are  the  key  advantages  to  this  network.  The  original 
problem  was  that  units  were  essentially  cut  off  from  any  substantial  logistic  support. 
Now  they  can  easily  request  support,  by  just  keying  a  few  characters  onto  a  packet 
radio.  No  couriers  or  courier  transportation  is  required  to  process  a  request.  The 
items  still  have  to  be  picked  up,  but  the  support  function  can  now  meet  the  customer 
halfway  or  possibly  even  establish  a  delivery  service;  the  source  being  placed  close  to 
the  customer. 


•"There  are  171  primitive  nodes. 
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C.       DISADVANTAGES 

1.  Radio 

As  with  any  radio  network,  it  is  less  reliable  than  hardwire  communications. 
Anyone  who  has  spent  time  in  the  field  knows  that  with  a  military  unit,  ground 
communication  by  radio  is  at  best  a  probabilistic  event.  The  major  weakness, 
therefore,  is  the  fact  that  data  is  transmitted  over  radio  waves  in  a  hostile  environment. 
In  view  of  this  a  great  deal  of  emphasis  must  be  placed  on  purchasing  quality  radio 
equipment. 

To  increase  reliability  we  could  reduce  the  baud  rate  from  9600  to  4800. 
While  this  would  decrease  the  cost  of  the  radio;  it  would  double  the  TDM  cycle  time. 
We  could  probably  cope  with  this  when  supporting  only  logistic  requests,  but  room  for 
expansion  to  meet  future  applications  would  be  reduced. 

2.  Frequency  Utilization  and  Throughput 

The  network  will  not  use  spectrum  efficiently  unless  frequency  hopping  shares 
channels  with  other  systems.  Multiple  FH  algorithms  will  improve  use  but  because  of 
the  hierarchical  nature  of  the  network  only  a  limited  number  of  packets  can  be 
processed  through  the  system.  Many  slots  will  not  be  used.  Even  if  even.'  node 
transmitted  a  packet  even."  30  seconds  constantly  for  a  10  hour  day  and  every  packet 
was  received  without  error  only  205.200  packets  could  be  processed.  In  a  10  hour  day 
there  are  720,000  time  slots.    So  the  upper  limit  of  spectrum  throughput  is  28.5%. 

3.  Delay 

TDM  with  210  nodes  at  1/20  second  transmission  time  develops  a  delay 
factor.  Even  dividing  up  the  network  into  four  FH  groups  does  not  improve  the  delay 
by  much  in  network  terms.  The  key  is  that  the  user,  transmitting  at  the  most  one 
packet  ever\T  30  seconds,  is  not  affected  by  the  delay. 

4.  User  Constraints 

This  network  is  designed  to  process  80  card  column  input.  It  will  accept 
paragraph  type  data  but  this  involves  a  cumbersome  process.  A  packet  radio  network 
is  designed  to  link  computers  and  is  not  intended  to  be  used  as  a  telegraph. 

There  is  also  a  constraint  on  the  flow  of  requisitions.  No  horizontal 
communication  is  allowed  because  there  is  no  perceived  need  to  send  logistic  requests 
to  a  neighbor. 
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5.  Cost 

The  hardware  is  the  biggest  cost  factor.  It  has  not  been  possible  to  obtain 
accurate  cost  figures  since  a  packet  radio  is  a  special  purpose  item:  however,  hardware 
costs  are  generally  decreasing  as  technology  improves.  Cost  may  or  may  not  be  a 
factor.  The  goal  is  to  purchase  a  low  cost  but  highly  reliable  packet  radio. 

6.  Security 

The  development  oi"  a  FH  algorithm  keyed  to  time  of  day  has  not  been 
attempted  in  this  thesis,  however,  this  is  conceivable  and  has  been  done  in  the  past  to 
support  other  communication  systems. 

D.       SUMMARY 

It  appears  that  a  packet  radio  network  will  solve  the  problem  of  logistic 
communication  on  the  battlefield.  Node  processing  is  kept  simple  while  the  network 
speed  provides  an  invaluable  service  to  the  customer.  The  network  is  flexible  because 
only  crucial  fields  are  automatically  error  checked  and  it  is  reliable  since  control 
functions  are  not  dependent  on  the  network  station.  Assets  can  be  visible  in  real  time 
and  can  be  accessed  in  seconds  from  anywhere  within  radio  range.  As  a  result, 
equipment  can  be  maintained  at  a  higher  level  of  readiness,  not  just  in  the  short  run. 
but  over  an  extended  period  of  time. 

The  tangible  benefit  of  this  packet  radio  network  is  the  fact  that  communicating 
the  bulk  of  logistic  demands  is  made  possible  while  deployed  even  when  the  support 
function  is  aboard  ship  and  the  time  required  for  logistic  support  is  reduced  from  days 
to  seconds.  The  need  to  communicate  all  battlefield  logistic  requests  in  seconds  must 
justify  the  cost  of  such  a  packet  radio  network.  In  this  thesis  we  have  provided  a 
prototype  design,  explained  specific  capabilities,  and  examined  network  characteristics. 
It  is  hoped  that  the  possibilities  identified  herein  will  inspire  more  detailed  technical 
research  so  that  the  described  benefits  mav  be  realized. 
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APPENDIX  A 
LIST  OF  ACRONYMS 

ALOHANET  -  One  of  the  original  Packet  radio  networks  established  in  Hawaii. 

ARPANET  -  One  of  the  first  networks  developed  using  packet  switching. 

AUTODIN  -  The  military  Data  communication  system. 

CSSIN  -  A  system  being  developed  by  the  Marine  Corps  to  organize  and 

account  for  assest  during  an  amphibious  landing. 

DET  -  A  detachment  or  unit  assigned  to  various  other  units. 

DMGS  -  A  system  developed  to  allow  data  communication  from  a  deployed  site 

to  the  closest  AUTODIN  switch. 

DOD  -  Department  of  Defense 

FH  -  Frequency  Hopping 

FSSG  -  The  Marine  Corp  Support  Element  (Force  Service  Support  Group). 

MAB  -  Marine  Amphibious  Brigade. 

MAF  -  Marine  Amphibious  Force  the  largest  type  landing  force. 

MAU  -  Marine  Amphibious  Unit  the  smallest  landing  force. 

MDSS  -  A  system  being  developed  by  the  Marine  Corps  that  attempts  to  provide 

the  landing  force  commander  with  asset  visibility. 

MPS  -  Marine  part  of  the  Rapid  deployment  force. 

NIS  -  Not  in  stock. 

NSN  -  National  stock  number  -  used  to  identify  and  warehouse  supply  items. 

PN  -  Pseudo  noise  modulation. 

RJE  -  Remote  job  entry. 

SASSY  -  The  Marine  Corps  automated  supply  system. 

SMU  -  SASSY  management  Unit  the  unit  in  the  FSSG  that  is  the  source  of 

supply  for  issue  points  and  is  the  section  the  inputs  and  distributes  SASSY 

output. 

TLOC  -  The  tactical  logistic  operation  center  which  receives  all  customer 

requests  and  directs  support  action. 

WRS  -  The  war  reserve  svstem  which  stocks  assest  for  use  onlv  durins  war. 
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APPENDIX  B 
MODEL 

1.  INTRODUCTION 

In  this  section  we  will  walk  through  how  a  packet  is  formed  and  how  it  proceeds 
through  the  system. 

2.  APPLICATION  LAYER 

When  a  logistic  need  is  identified  the  user  turns  on  the  packet  radio,  looks  up  the 
appropriate  format  in  the  data  dictionary  and  keys  the  request.  Once  the  enter  key  is 
pressed  the  packet  goes  to  the  next  step. 

3.  PRESENTATION  LAYER 

At  this  point  the  request  is  converted  to  a  6  bit  code  and  input  error  detection  is 
accomplished. 

4.  SESSION  LAYER 

The  session  is  predefined  by  the  TDM  protocol  and  routing  is  predetermined. 
The  unit  ID  is  replaced  with  an  eight  bit  unit  identification  code  and  the  Julian  data  is 
stripped  from  the  data. 

5.  TRANSPORT  LAYER 

The  packet  is  formed.  The  address  of  the  sender  is  placed  in  the  header,  the 
request  is  placed  in  the  data  section.  A  copy  of  the  data  section  of  the  packet  is  placed 
into  the  pending  acknowledgment  file.  A  program  to  count  the  number  of 
retransmissions  and  set  the  distress  bit  if  necessary  is  run. 

6.  NETWORK  LAYER 

There  is  no  end  to  end  protocol  except  the  response  that  is  generated  by  the 
application  layer.   The  routing  bit  is  added  to  the  header. 

7.  DATA  LINK  LAYER. 

The  CRC  and  hamming  parity  bits  are  generated.  The  packet  now  waits  for  its 
assigned  time  slot. 
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8.  PHYSICAL  LAYER 

The  packet  is  transmitted  by  converting  the  bits  into  radio  waves.  The 
destination  converts  the  packet  to  the  6  bit  code  being  used. 

9.  DATA  LINK  LAYER 

The  destination  reads  the  preamble  and  performs  hamming  correction. 

10.  NETWORK  LAYER 

The  destination  determines  whether  to  accept  the  packet  or  ignore  it. 

11.  DATA  LINK  LAYER 

If  the  destination  accepts  the  packet  the  whole  packet  is  read  and  error 
correction  and  detection  are  performed. 

12.  NETWORK  LAYER 

The  destination  determines  whether  to  process  the  packet  or  pass  it  automatically 
to  the  next  level  of  support  in  which  case  the  whole  process  starts  again  at  the 
transport  layer. 

13.  TRANSPORT  LAYER 

If  the  packet  was  to  be  processed  then  and  error  check  bits  and  address  would  be 
stripped  off  the  packet.  The  packet  radio  would  send  a  request  for  interrupt  to  the 
attached  processor.  Otherwise,  a  new  address  would  be  placed  in  the  header.  In  either 
case  an  acknowledgment  packet  would  be  structured  and  sent  in  the  same  way  as  the 
data  packet  was  sent. 

14.  SESSION  LAYER 

The  attached  processor  would  perform  an  interrupt  if  necessary.  The  eight  bit 
unit  identification  would  be  converted  to  a  standard  6  character  unit  ID  code.  The 
appropriate  Julian  date  would  also  be  inserted. 

15.  PRESENTATION  LAYER 

The  data  in  the  packet  would  be  converted  to  the  proper  code  from  the  6  bit 
network  code. 

16.  APPLICATION  LAYER 

The  request  would  be  processed  in  accordance  with  the  structured  chart. 
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APPENDIX  C 
SPECIFICATIONS  FOR  NETWORK  HARDWARE 

1.        FOR  STAND  ALONE  PACKET  RADIO 

1.  Be  small  enough  to  he  hand  carried  not  necessarily  hand  held. 

2.  Be  batten-  powered  with  the  option  of  being  powered  by  a  generator. 

3.  Be  capable  of  hopping  frequencies  every  120  of  a  second. 

4.  Have  enough  precision  to  maintain  1  20  second  synchronization. 

5.  Be  phase  keyed  modulation  compatible. 

6.  Be  able  to  interpret  signals  at  a  rate  up  to  9600  baud. 

7.  Have  26  data  keys,  a  shift  key,  an  enter  key  and  2  cursor  keys,  forward 

and  backward  to  edit  messages  prior  to  transmission. 

8.  Have  a  160  character  display:  80  for  the  input  document  and  80  for  received 

documents.    Also  a  4  digit  wide  display  to  view  all  pending  documents  10  at 
a  time  is  necessary. 

9.  Use  an  omnidirectional  antenna. 

10.  Be  able  to  perform  matched  filtering  and  correlation. 

11.  Perform  modulation  that  sends  one  bit  per  signal. 

12.  Have  a  small  buffer  to  contain  two  or  three  packets. 

13.  Have  a  64  K  memory. 

To  maintain  a  history  file. 

To  store  and  implement  a  FH  algorithm. 

To  maintain  a  pending  response  file. 

To  store  a  program  to  convert  data  to  6  bit  network  code. 

To  store  a  program  to  obtain  the  16  bit  CRC  check. 

To  store  a  program  to  implement  an  acknowledgment  scheme 

14.  Be  able  to  connect  to  a  printer  to  print  history  file. 

15.  Ability  to  display  any  pending  acknowledgment. 

16.  Do  preamble  detection.     Listen  to  all  traffic  but  process  only  that  which 
applies. 

17.  Cost  per  unit  less  than  S3,000. 
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18.  Maintenance   modularized   to    permit    easy   replacement    of  failed   sections 
without  a  lot  of  analysis. 

19.  Mean  time  between  failure  less  than  600  hours. 

20.  Be  ruggedized. 

2.  FOR  A  SIMPLE  REPEATER 

A  simple  repeater  would  have  the  same  specifications  as  the  stand  alone  packet 
radio  except  for  specifications  7,8,15,17  and  13.  Also,  the  size  constraint  would  be  less 
stringent.  But  the  buffer  size  requires  storage  for  up  to  25  packets.  Also  the  cost 
constraint  would  be  reduced  to  S2.000. 

3.  FOR  AN  ATTACHED  REPEATER 

The  specifications  for  this  type  of  repeater  would  be  the  same  as  those  for  the 
simple  repeater.  The  only  additional  function  is  that  it  should  have  the  capability  to  be 
programmed  by  the  user  to  automatically  pass  certain  types  of  packets  but  at  the  same 
time  send  a  copy  of  that  packet  to  the  terminal  equipment  for  record  purposes.  Also, 
some  of  the  memory  and  programming  functions  could  be  shared  with  the  terminal 
equipment.   Power  also  should  be  provided  primarily  by  the  terminal. 
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